Le service WCF a échoué dans l'authentification sur le serveur 2012 mais OK dans Win7?

Question

J'avais créé un service de WCF avec authentification et autorisation de base de rôle. Et la mise en œuvre de chaque opération est comme

[PrincipalPermission(SecurityAction.Demand, Role = RoleConstants.Customer)]
[PrincipalPermission(SecurityAction.Demand, Role = RoleConstants.CustomerStaff)]
public void DoSomething()
{
}

Le fournisseur d'adhésion et Rolemanager sont ceux pour MySQL, pas dans GAC. Les certificats SSL sont générés par IIS 7 pour HTTPS.

et j'ai des tests d'intégration comme

using (var client = new MyProxy("DefaultBinding_ILicensingService"))
{
    client.ClientCredentials.UserName.UserName = "AbcShop";
    client.ClientCredentials.UserName.Password = "tttttttt";

    client.DoSomething();
}

Une instance est en cours d'exécution sur ma machine Dev de Win7, et l'autre est sur un serveur de test du serveur 2012. Les deux cas du service WCF fonctionnaient bien.

Cependant, après 1 mois, j'ai constaté que l'instance sur Server 2012 ne fonctionne plus et a échoué lors de l'authentification, avec le message suivant.

mise à jour:

System.ServiceModel.Security.MessageSecurityException : An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
---- System.ServiceModel.FaultException : An error occurred when verifying security for the message.
Stack Trace:

Server stack trace: 
   at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)
   at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

mise à jour:

J'ai observé ce qui suit et j'ai exclu certaines causes possibles.

1. Les bases de données d'authentification des deux machines sont identiques et je pouvais voir que le service WCF fait des requêtes SQL pour récupérer les informations des membres après une demande de la demande.
2. J'avais comparé la liaison et les paramètres IIS, ainsi que web.config sur les deux machine, qui sont essentiellement identiques, à l'exception des adresses.
3. Le visualiseur d'événements ne montre aucun avertissement sur le service WCF.
4. La mise en œuvre du service de la WCF est décorée par cela attribuée: Erreur de classe publiqueHandlerbehaviorattribute: Attribut, IserviceBehavior, iErrorhandler et toutes les exceptions non capturées iront à cet attribut qui enregistrera les erreurs dans un fichier journal, cependant, le fichier journal n'a rien enregistré pour cette affaire.

Et j'avais comparé les assemblages chargés dans les deux cas. Sous Windows 7, les assemblages système sont fondamentalement à partir de Windows \ Microsoft.net \ Assembly \ gacxxx \ xxx, cependant dans Server 2012, certains assemblages proviennent de Windows \ Assembly \ Napatimages_v4.0.30319_64, voici quelques assemblages situés dans des Nativeimages:

System   
System.Activities   
System.Core   
System.Data.DataSetExtensions   
System.Drawing   
System.Enumerics
System.ServiceModel.Activities   
System.WorkflowServices   
System.XAML   
System.ServiceModel.Web

En revanche, dans la victoire 7, seul le système provient de natifimages. Je ne sais pas si l'emplacement des assemblages ou des images natales pouvait modifier les comportements.

Les services et les clients sont développés à l'aide de VS 2012 sur .NET Framework 4.5.

Que pourrait éventuellement faire l'instance sur le serveur 2012 échoue?

Answer 1

problèmes résolus.

La racine des causes: assemblages MVC ASP .NET manquants dans le serveur 2012.

L'arrière-plan est, je souhaite que le service WCF partage la même base de données d'authentification avec des applications MVC à construire à l'avenir. Ainsi, le fournisseur de membre et le gestionnaire d'authentifiant sont ceux de MVC et la base de données est MySQL, les fournisseurs sont donc à partir d'une composante 3ème partie open source qui est couplée à MVC.

Les raisons pour lesquelles mon gestionnaire d'exception et mon séjour d'événement non capturé ne pouvaient pas attraper des avertissements sur les assemblées manquantes sont: 1. Le PC DEV a été utilisé par un développeur antérieur qui a aimé GAC. Vous savez que GAC pourrait causer beaucoup de problèmes dans un PC Dev. Des tonnes d'assemblage de MVC 1,2 et 3 étaient dans GAC. 2. Le 3ème composant interagissant avec MVC a une mauvaise pratique de programmation quelque part avaler quelques exceptions sur les assemblages manquants.

Après avoir comparé des assemblages chargés un par un dans les deux machine, j'ai trouvé que l'instance de service WCF sur le serveur 2012 n'avait pas de webmatrix.webdata.dll. Après avoir copié l'assemblage sur le répertoire bin du répertoire virtuel, j'ai eu une chaîne de messages d'erreur sur des assemblys plus manquants après que j'ai copié les assemblages manquants signalés un par un. Ces assemblages appartiennent essentiellement à MVC. Les messages d'erreur sont apparus sur le côté du client dans la réponse du service en HTML, ainsi que sur la visionneuse d'événements du côté serveur.

Donc, je m'assure maintenant les scripts de déploiement pour inclure des assemblages respectifs.

Apparemment, une fois que le service a récupéré les informations de membre de la base de données d'authentification, le service déléguera les informations à d'autres assemblages de MVC pour un traitement ultérieur et la 3ème composante avalait l'exception des assemblys manquants. Et les autres parties de l'authentification ont un signal incorrect, puis donnaient un message d'avertissement trompeur sur «Vérification de la sécurité ...».

La leçon est: 1. Ne pas GAC dans la machine DEV. Si vous avez hérité d'une machine DEV de quelqu'un, mieux d'investir un peu à l'ONU-GAC, certains devraient être des assemblées privées via XCopy. 2. Certaines composantes tierces pourraient avoir une certaine pratique sale contre la programmation défensive. Dans mon cas, le composant a avalé les avertissements sur les assemblées manquantes. 3. Il est moins cher de comparer des assemblages chargés avant d'enquêter sur d'autres causes possibles. J'utilise Process Explorer pour répertorier les assemblages chargés dans W3WP.EXE.