Il servizio WCF non è riuscito nell'autenticazione su Server 2012 ma è OK in Win7?

Question

Avevo creato un servizio WCF con autenticazione e autorizzazione della base dei ruoli.E l'implementazione di ogni operazione è simile

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

Il provider di appartenenze e RoleManager sono quelli per MySql, non in GAC.I certificati SSL sono generati da IIS 7 per https.

E ho alcuni test di integrazione come

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

    client.DoSomething();
}

Un'istanza è in esecuzione sul mio computer di sviluppo Win7 e l'altra su un server di prova Server 2012.Entrambe le istanze del servizio WCF funzionavano bene.

Tuttavia, dopo 1 mese, ho scoperto che l'istanza sul Server 2012 non funziona più e l'autenticazione non è riuscita, con il seguente messaggio.

Aggiornamento:

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)

Aggiornamento:

Ho osservato quanto segue e ho escluso alcune possibili cause.

1. I database di autenticazione su entrambe le macchine sono identici e ho potuto vedere che il servizio WCF sta effettuando query SQL per recuperare le informazioni sui membri dopo che il client ha effettuato una richiesta.
2. Ho confrontato il collegamento e le impostazioni di IIS, nonché web.config su entrambe le macchine, che sono sostanzialmente identiche tranne alcuni indirizzi.
3. Il Visualizzatore eventi non mostra alcun avviso relativo al servizio WCF.
4. L'implementazione del servizio WCF è decorata da questo attributo:classe pubblica ErrorHandlerBehaviorAttribute:Attributo, IServiceBehavior, IErrorHandler e tutte le eccezioni non rilevate andranno a questo attributo che registrerà gli errori in un file di registro, tuttavia, il file di registro non ha registrato nulla a riguardo.

E avevo confrontato gli assembly caricati in entrambi i casi.In Windows 7, gli assembly di sistema provengono fondamentalmente da Windows\Microsoft.NET\assembly\GACXXX\XXX, tuttavia in Server 2012 alcuni assembly provengono da Windows\assembly ativeImages_v4.0.30319_64, ecco alcuni assembly situati in NativeImages:

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

Al contrario, in Win 7, solo System proviene da NativeImages.Non sono sicuro che la posizione degli assiemi o delle immagini native possa alterare i comportamenti.

I servizi e i client sono sviluppati utilizzando VS 2012 su .NET Framework 4.5.

Cos'altro potrebbe far fallire l'istanza su Server 2012?

Answer 1

Problemi risolti.

La radice delle cause:assembly ASP .NET MVC mancanti nel Server 2012.

Lo sfondo è che desidero che il servizio WCF condivida lo stesso database di autenticazione con le applicazioni MVC da creare in futuro.Quindi il provider membro e il gestore di autenticazione sono quelli di MVC e il database è MySql, quindi i provider provengono da un componente di terze parti open source accoppiato con MVC.

I motivi per cui il mio gestore di eccezioni non rilevate e il Visualizzatore eventi non sono riusciti a rilevare gli avvisi sugli assembly mancanti sono:1.Il PC di sviluppo è stato utilizzato da uno sviluppatore precedente che amava GAC.Sai che GAC potrebbe causare molti problemi in un PC di sviluppo.Tonnellate di assemblaggi da MVC 1,2 e 3 erano in GAC.2.Il terzo componente che interagisce con MVC ha da qualche parte delle pratiche di programmazione scadenti che ingoiano alcune eccezioni sugli assembly mancanti.

Dopo aver confrontato gli assembly caricati uno per uno su entrambe le macchine, ho scoperto che l'istanza del servizio WCF sul Server 2012 non aveva WebMatrix.WebData.dll.Dopo aver copiato l'assembly nella directory bin della directory virtuale, ho ricevuto una catena di messaggi di errore su più assembly mancanti dopo aver copiato gli assembly mancanti segnalati uno per uno.Questi assembly appartengono fondamentalmente a MVC.I messaggi di errore apparivano lato client nella risposta del servizio in HTML, così come nel Visualizzatore eventi lato server.

Quindi ora mi assicuro che gli script di distribuzione includano i rispettivi assembly.

Apparentemente dopo che il servizio ha recuperato le informazioni sui membri dal database di autenticazione, il servizio delegherà le informazioni ad altri assembly di MVC per un'ulteriore elaborazione e in qualche modo il terzo componente ha inghiottito l'eccezione sugli assembly mancanti.E le altre parti dell'autenticazione hanno ricevuto un segnale sbagliato e quindi hanno fornito un messaggio di avviso fuorviante su "Verifica della sicurezza...".

La lezione è:1.Non eseguire GAC nella macchina di sviluppo.Se hai ereditato una macchina di sviluppo da qualcuno, è meglio investire del tempo per annullare il gac di alcuni che avrebbero dovuto essere assembly privati ​​tramite XCopy.2.Alcuni componenti di terze parti potrebbero avere delle pratiche sporche contro la programmazione difensiva.Nel mio caso, il componente ha inghiottito gli avvertimenti sugli assiemi mancanti.3.È più economico confrontare gli assiemi caricati prima di indagare su altre possibili cause.Utilizzo Process Explorer per elencare gli assembly caricati in w3wp.exe.