キャッチ22により、ストリーミングされたTCP WCFサービスがWIFでセキュリティ保護されなくなり、クリスマスと精神衛生が台無しになる 質問する

WCF には、ストリーミングに関するいくつかの領域で問題があります (MTOM ¹がそうです)。これは、ほとんどの人が期待するとおりに事前認証を実行できないという根本的な問題が原因です (これは、そのチャネルの後続のリクエストにのみ影響し、最初のリクエストには影響しません)。わかりました。これはまさにあなたの問題ではありませんが、最後にあなたの問題について説明しますので、このまま読み進めてください。通常、HTTP チャレンジは次のように機能します。

1. クライアントが匿名でサーバーにアクセスする
2. サーバーは、申し訳ありませんが、401、認証が必要ですと表示します
3. クライアントは認証トークンを使用してサーバーにアクセスします
4. サーバーが受け入れます。

これで、サーバーの WCF エンドポイントで MTOM ストリーミングを有効にしようとしても、エラーは発生しません。ただし、クライアント プロキシでこれを構成すると (そうすべきです。バインディングが一致している必要があります)、爆発して焼死します。その理由は、WCF が防止しようとしている上記の一連のイベントが次のとおりであるためです。

1. クライアントは1回のPOSTで100MBのファイルを匿名でサーバーにストリーミングする
2. サーバーは申し訳ありませんが、401、認証が必要ですと表示しています
3. クライアントは認証ヘッダー付きの100MBのファイルを再度サーバーにストリーミングします。
4. サーバーが受け入れます。

100MB しか送信する必要がなかったのに、200MB をサーバーに送信してしまったことに注意してください。これが問題です。答えは最初の試行で認証を送信することですが、WCF ではカスタム動作を記述しないとこれは不可能です。とにかく、話がそれました。

あなたの問題

まず、あなたがしようとしていることは不可能だということをお伝えします²。では、無駄な努力をやめるために、その理由を説明しましょう。

あなたも今、同じような問題に巻き込まれているように私には思えます。メッセージ レベルのセキュリティを有効にすると、クライアントは、ws-security で必要な通常のハッシュ関数と XML 署名を使用して実際にメッセージを閉じる前に、データのストリーム全体をメモリにロードする必要があります。ストリーム全体を読み取って単一のメッセージ (実際にはメッセージではありませんが、単一の連続ストリームです) に署名する必要がある場合、ここで問題がわかります。WCF は、メッセージ セキュリティを計算するためにそれを「ローカル」で 1 回ストリーミングし、次にそれを再度ストリーミングしてサーバーに送信する必要があります。これは明らかにばかげたことです。そのため、WCF はストリーミング データに対してメッセージ レベルのセキュリティを許可しません。

したがって、ここでの簡単な答えは、トークンを最初の Web サービスへのパラメータとして、または SOAP ヘッダーとして送信し、カスタム動作を使用して検証する必要があるということです。これを行うために WS-Security を使用することはできません。率直に言って、これは WCF だけの問題ではありません。他のスタックで実際に機能する方法がわかりません。

MTOM問題の解決

これは、私が基本認証の MTOM ストリーミングの問題を解決した例に過ぎないので、おそらくこれを参考にして、自分の問題にも同様のものを実装できるでしょう。重要なのは、カスタム メッセージ インスペクターを有効にするには、トランスポート レベル (SSL) を除き、クライアント プロキシのセキュリティの概念をすべて無効にする必要があることです (サーバーでは有効のままです)。

this._contentService.Endpoint.Behaviors.Add(
    new BasicAuthenticationBehavior(
        username: this.Settings.HttpUser,
        password: this.Settings.HttpPass));
var binding = (BasicHttpBinding)this._contentService.Endpoint.Binding;
binding.Security.Mode = BasicHttpSecurityMode.Transport; // SSL only            
binding.Security.Transport.ClientCredentialType = 
   HttpClientCredentialType.None; // Do not provide

internal class BasicAuthenticationBehavior : IEndpointBehavior
{
    private readonly string _username;
    private readonly string _password;

    public BasicAuthenticationBehavior(string username, string password)
    {
        this._username = username;
        this._password = password;
    }
    public void AddBindingParameters(ServiceEndpoint endpoint, 
        BindingParameterCollection bindingParameters) { }
    public void ApplyClientBehavior(ServiceEndpoint endpoint,
        ClientRuntime clientRuntime)
    {
        var inspector = new BasicAuthenticationInspector(
            this._username, this._password);
        clientRuntime.MessageInspectors.Add(inspector);
    }
    public void ApplyDispatchBehavior(ServiceEndpoint endpoint,
        EndpointDispatcher endpointDispatcher) { }
    public void Validate(ServiceEndpoint endpoint) { }
}

internal class BasicAuthenticationInspector : IClientMessageInspector
{
    private readonly string _username;
    private readonly string _password;

    public BasicAuthenticationInspector(string username, string password)
    {
        this._username = username;
        this._password = password;
    }

    public void AfterReceiveReply(ref Message reply,
        object correlationState) { }

    public object BeforeSendRequest(ref Message request,
        IClientChannel channel)
    {
        // we add the headers manually rather than using credentials 
        // due to proxying issues, and with the 101-continue http verb 
        var authInfo = Convert.ToBase64String(
            Encoding.Default.GetBytes(this._username + ":" + this._password));

        var messageProperty = new HttpRequestMessageProperty();
        messageProperty.Headers.Add("Authorization", "Basic " + authInfo);
        request.Properties[HttpRequestMessageProperty.Name] = messageProperty;

        return null;
    }
}