Existe-t-il un moyen de dire à WCF d'utiliser la sécurité dans la requête, mais de l'ignorer dans la réponse?

Question

Nous devons nous connecter à un service SOAP tiers et nous utilisons WCF pour le faire. Le service a été développé en utilisant Apache AXIS, et nous n'avons aucun contrôle sur celui-ci, et nous n'avons aucune influence pour changer son fonctionnement. Le problème que nous voyons est qu'il s'attend à ce que les demandes soient formatées en utilisant la sécurité des services Web, donc nous faisons toute la bonne signature, etc. La réponse de la 3ème partie n'est cependant pas sécurisée. Si nous reniflons le fil, nous voyons la réponse revenir bien (mais sans aucun horodatage, signature, etc.). Les composants .NET sous-jacents affichent cette erreur comme une erreur car elle la considère comme un problème de sécurité. Par conséquent, nous ne recevons pas la réponse de savon en tant que telle. Existe-t-il un moyen de configurer le cadre WCF pour envoyer des demandes sécurisées, mais ne pas attendre des champs de sécurité dans la réponse? En regardant les spécifications OASIS, il ne semble pas exiger que les réponses doivent être sécurisées.

Pour plus d'informations, voici l'exception que nous voyons:

L'exception que nous recevons est:

System.ServiceModel.Security.MessageSecurityException was caught 
    Message="Security processor was unable to find a security header in the message. This might be because the message is an unsecured fault or because there is a binding mismatch between the communicating parties. This can occur if the service is configured for security and the client is not using security." 
    Source="mscorlib" 
    StackTrace: 
    Server stack trace: 
     at System.ServiceModel.Security.TransportSecurityProtocol.VerifyIncomingMessageCore(Message& message, TimeSpan timeout) 
     at System.ServiceModel.Security.TransportSecurityProtocol.VerifyIncomingMessage(Message& message, TimeSpan timeout) 
     at System.ServiceModel.Security.SecurityProtocol.VerifyIncomingMessage(Message& message, TimeSpan timeout, SecurityProtocolCorrelationState[] correlationStates) 
     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.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout) 
     at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) 

Soit dit en passant, j'ai vu beaucoup de messages indiquant que si vous laissez l'horodatage de sortie, puis le les champs de sécurité ne seront pas attendus. Ce n'est pas une option - Le service que nous communiquons avec les timestamps des mandats.

Answer 1

Drôle, vous devriez poser cette question. J'ai demandé à Microsoft comment faire cela il y a environ un an. À l'époque, en utilisant .NET 3.0, ce n'était pas possible. Je ne sais pas si cela a changé dans le monde 3.5. Mais, non, il n'y avait aucun moyen physique d'ajouter de la sécurité à la demande et de laisser la réponse vide.

Chez mon employeur précédent, nous utilisions un modèle qui nécessitait un en-tête WS-Security en utilisant des certificats sur la demande mais la réponse n'était pas sécurisée.

Vous pouvez le faire avec les services Web ASMX et WSE, mais pas avec WCF v3.0.

Answer 2

Il y a de fortes chances que vous ne puissiez pas vous en sortir seul. J'ai dû faire un travail d'intégration avec Axxis (notre fin était l'ancêtre de WSE3 - WCF), et j'ai dû écrire du code et le coller dans le pipeline de WSE3 pour masser la réponse d'Axxis avant de le transmettre à WSE3. Les bonnes nouvelles sont que l'ajout de ces gestionnaires au pipeline est assez simple, et une fois dans le gestionnaire, vous obtenez juste une instance d'un SoapMessage, et pouvez faire tout ce que vous voulez avec lui (par exemple supprimer l'horodateur)

Answer 3

Microsoft dispose d'un correctif pour cette fonctionnalité maintenant.

http://support.microsoft.com/kb/971493