the minimum WS-Security on SecurityBindingElement

たぶん↓が一番簡単なWS-SecurityをサポートするBinding

AsymmetricSecurityBindingElement sbe =
  new AsymmetricSecurityBindingElement ();
sbe.SecurityHeaderLayout = SecurityHeaderLayout.Lax; // 1.ゆる〜く
sbe.RequireSignatureConfirmation = false; // 2.な〜も確認しない
sbe.LocalServiceSettings.DetectReplays = false; // 3.リプレイなんてｼﾗｿ
sbe.IncludeTimestamp = false; // 4.いつ作られたメッセージでもｷﾆｼﾅｲ!
sbe.RecipientTokenParameters = new X509SecurityTokenParameters (
  X509KeyIdentifierClauseType.Thumbprint,
  SecurityTokenInclusionMode.Never);
sbe.InitiatorTokenParameters = new X509SecurityTokenParameters (
  X509KeyIdentifierClauseType.Thumbprint,
  SecurityTokenInclusionMode.AlwaysToRecipient);
sbe.SetKeyDerivation (false); // 5.鍵なんて毎回同じ奴でおｋ
sbe.MessageProtectionOrder =
  MessageProtectionOrder.SignBeforeEncrypt;
HttpTransportBindingElement hbe =
  new HttpTransportBindingElement ();
CustomBinding binding = new CustomBinding (sbe, hbe);

WSHttpBindingなんてク　じゃあ、と思った人はどうぞ。＜違いすぎ

WSHttpBindingを使うことしか知らない人がここまでたどり着くまでどれくらいかかるかは、まあ、何とも言えない。

これならmonoでもとりあえず通信はできる。あんまし安全じゃないけど。

解説編: *1 *2 *3 *4 *5

*1:WS-SecurityPolicyではwsse:Securityの内容の順番がうるさく規定してある。

*2:RequireSignatureConfirmationというのは、受信側からの応答メッセージに含まれる「署名ヲ確認セヨセリ」というセキュリティヘッダ項目。

*3:タイムスタンプが古いものをチェックしないと、同じ内容のメッセージが後で送りつけられても処理できてしまう。

*4:Timestampの無いメッセージのリプレイは検出できない。DetectReplays=trueの場合、そのようなメッセージは拒絶される。

*5:暗号鍵を公開メッセージで使い回していると、破られる危険性も大きくなる。