これはすべて、カスタム サービス ホストでホストされている WebHttp バインディングに関するものです (現時点では IIS はオプションではありません)。
カスタム UserNamePasswordValidator とカスタム IAuthorizationPolicy を実装しました。基本認証を使用するようにエンドポイントのバインドを構成すると、すべてが思いどおりに機能します (カスタム プリンシパル、カスタム ロールなど)。
匿名 HTTP アクセスの機能も追加し、カスタム実装で匿名ユーザーをいくつかのデフォルト ロールなどに配置したいと考えています (Authenticate ヘッダーが送信されない場合)。
これで、私のカスタム コードがヒットする前に、匿名ユーザーに 401 が与えられるようになりました。HTTP 基本認証要件をオフにすると、Authenticate ヘッダーは完全に無視されます。
これを両方の方法で (2 つの別個のエンドポイントを作成せずに) 行うには、どのように構成または Authenticate ヘッダーを挿入しますか?
まず、仕様に従って、サービスは匿名の呼び出しに正しく応答します。
第二に、これは不可能です。サービスを自己ホストしていて、何らかの http バインディングがある場合、WCF はSystem.Net.HttpListenerインスタンスを使用して、http 要求 (で作成) に応答できるようにしますSystem.ServiceModel.Channels.SharedHttpTransportManager.OnOpen。このリスナーにはHandleAuthentication、カスタム コードが呼び出される前に呼び出されるメソッドがあります。これは、チャレンジ (WWW-Authenticate) で 401 応答を返す責任があります。これについてあなたができることは何もありません。あるなら、知りたいです。
したがって、次のオプションが残されています。
私は過去にこれについて調査しましたが、2つの別々のエンドポイントを作成しない限り、構成では不可能であることがわかりました（これはあなたが望むものではありません）。WCFではそのままではサポートされていません。
ただし、WCFは非常にカスタマイズ可能であり、必要な処理を実行するカスタムチャネル/バインディングを作成することでこれを実行できる可能性があります。RESTチェスのソースコードをご覧になることをお勧めします。それはあなたが始めるはずです。
最善の策は、ロール プロバイダーを介して既定のロールを実装し、匿名ユーザーがそのロールに自動的に参加できるようにすることです。次に、プログラムによって、またはポリシー インジェクション (アスペクト指向) ポリシーを介して、特定のロールを介して特定の匿名アクセスが許可されるように設定します。
これを構成で設定することに関しては、可能であれば、かなり難しく、一種の「ハッキー」になります。
私はそうは思いません...私はあなたの質問をもう一度読むことに決め、あなたの質問の最後の声明に気づいたとき、別のエンドポイントを作成する必要があると書いていました. したがって、答えはノーです（私が知っていることです）