WCF WebHttp混合認証（基本および匿名）

Question

これらはすべて、カスタムサービスホストでホストされるWebHttpバインディングに関連しています（現時点では、IISはオプションではありません）。

カスタムUserNamePasswordValidatorとカスタムIAuthorizationPolicyを実装しました。基本認証を使用するようにエンドポイントのバインディングを構成すると、すべてが希望どおりに機能します（カスタムプリンシパル、カスタムロールなど）。

匿名HTTPアクセスの機能も追加し、カスタム実装に匿名ユーザーをデフォルトのロールなどに配置させます。（認証ヘッダーが送信されない場合）

今起こっていることは、カスタムコードがヒットする前に匿名ユーザーに401が与えられることです。 HTTP基本認証要件をオフにすると、認証ヘッダーは完全に無視されます。

2つの別個のエンドポイントを作成せずに両方の方法でこれを行うには、どのように構成、認証ヘッダーを挿入しますか？

Answer 1

まず、仕様に従って、サービスは匿名呼び出しに正しく応答します。

第二に、これは不可能です。サービスをセルフホストし、httpバインディングがある場合、WCFは System.Net.HttpListener インスタンスがhttp要求に応答できるようにします（ System.ServiceModel.Channels.SharedHttpTransportManager.OnOpen で作成） 。このリスナーには、カスタムコードが呼び出される前に呼び出される HandleAuthentication というメソッドがあります。チャレンジ（WWW-Authenticate）とともに401応答を送り返す役割を果たします。これについてできることは何もありません。あれば、知りたいです。

したがって、次のオプションが残ります。

• 2つのエンドポイント
• デフォルトの資格情報を知るようにクライアントを構成します
• クライアントがチャレンジに対応できるように変更します

Answer 2

これについては過去に調査しましたが、2つの別個のエンドポイントを作成しない限り、構成によっては不可能であることがわかりました（これは望んでいないものです）。単にWCFでサポートされていないだけです。

ただし、WCFは非常にカスタマイズ可能であり、必要なことを行うカスタムチャネル/バインディングを記述することでこれを行うことができます。 REST Chess ソースコードをご覧になることをお勧めします。始めるはずです。

Answer 3

最善の方法は、ロールプロバイダーを介してデフォルトのロールを実装し、匿名ユーザーがそのロールに自動的に参加できるようにすることです。次に、プログラムによって、またはポリシーインジェクション（アスペクト指向）ポリシーを介して、特定のロールを介して特定の匿名アクセスが許可されるように設定します。

設定を介してこれを設定する場合、可能であれば、それはかなり難しく、「ハッキング」のようなものです。

Answer 4

そうは思わない...質問をもう一度読み、質問の最後の声明に気づいたとき、別のエンドポイントに作成する必要があると書いていた。だから答えはノーだろう（私は知っている）