2007-02-07

■

せっかくなので僕も1回だけWCFのクラスについて説明を書いてみようかな。ということで、System.ServiceModel.MessageSecurityVersionについて。たまには読みやすいものを書かないと。

このクラスには4つのstatic readonlyなプロパティがある。

• WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10
• WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11
• WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10
• Default

以前にもちらっと言及した通り、WSHttpBindingで使われているのはDefaultことWSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11 ではなくWSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10である。

最初のプロパティWSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10は、他の2つと違って、WS-Security 1.0をサポート対象としている。これによって、たとえば要求者に応答者が返すメッセージには、WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10の場合にはwss11:SignatureConfirmation要素が含まれないが、WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11やWSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile1の場合には含まれるということになる。

WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11 とそれ以外の違いは、WS-I Basic Security Profileをサポートしているか否か、という点に尽きる（と思われる）。これは、たとえばそのMessageSecurityVersionを指定されたSecurityBindingElementとChannelFactoryのClientCredentialsから生成されたSecurityTokenManagerからCreateSecurityTokenSerializer()で生成されたWSSecurityTokenSerializerのEmitBspRequiredAttributes属性の値の違いになり、その帰結として、X509SecurityTokenを外部参照するSecurityTokenReference要素に含まれるKeyIdentifier要素にEncodingType属性が付くか付かないか、といった違いになる（自分でWSSecurityTokenSerializerにEmitBspAttributes=trueを設定すれば、EncodingTypeは出力されなくなるが、そこまでWCFをいじっている人は多くないかもしれない）。ちなみにX509SecurityTokenを外部参照するSecurityTokenReferenceは、X509ThumbprintKeyIdentifierClauseというクラスになっている。これをWSSecurityTokenSerializer.WriteKeyIdentifierClause()でXMLにしてみれば分かる。

サービスでMessageSecurityVersionのプロパティにもあるSecurityTokenVersionについても言及しておこう。これはSecurityTokenManager.CreateSecurityTokenSerializer()の引数として利用され、具体的にはWSSecurityTokenSerializerがBasic Security Profile 1.0を考慮するかしないかに影響してくる（SecurityTokenVersion.GetSecuritySpecifications()の戻り値にBasic Security Profile 1.0のURIが有るか無いかで決定できる）。WSHttpBindingとClientBaseからここまでは、全て公開APIのレベルで再現できるパズルである。

他にもいろいろな動作の違いが考えられる。たとえばWSDLを出力したときのwsp:Policyの内容は異なってくるだろう。

ということで、ごくあっさりとした紹介になりましたが、MessageSecurityVersionクラスも掘り下げれば興味深いと思うので、興味がある人は是非チェックしてみましょう。

本当にエラーの詳細を知りたい場合は

ServiceDebugBehavior.IncludeExceptionDetailInFaults（正確にはChannelDispatcher.IncludeExceptionDetailInFaults）の情報なんて大したものは含まれないのです。実際に開発していて本当に必要になるのは/configuration/system.diagnostics/sources/source[@name=‘System.ServiceModel’]だと思います。

効率の問題

ミもフタもない話なんだけど、データベース研究者を1人探すより、何万人も助かる可能性のある薬品の研究に必要な計算にリソースを提供する方が効率的じゃん?とか思うんだよね（いや新薬がどうこうっていう問題じゃないって話もあるけど）。京都議定書の実行にかかるコストで、途上国の衛生状態を改善して膨大な人命を救うことが出来るっていう議論と同じで。

とはいえ、衛星写真と手すきのマンパワーを活用して問題を解決する、っていう試みは、技術的にはきっと面白いことだと思うので、興味がある人は祭りに参加して体験してみるっていうのもいいんじゃないかな。宇宙人探すよりは有意義だろうし。