SilverLightとWPFクライアントインターフェイスの両方を対象とするアプリケーションに対してWCF認証を処理するためのアドバイスを探しています。SilverLight 4とWPFアプリケーションの両方でWCF認証を処理する方法
編集：実際には、認証モードにはユーザー名とパスワードの組み合わせが必要です。
さらに、将来、アプリケーションは完全スタンドアロンモード（クライアント（WPF）と同じアプリケーション内の同じコンピュータ上のサーバー）で動作する必要があります。その場合、WCFを使用しないでください。
EDIT：もう1つの追加として、アプリケーションはゲームのようにローカルネットワークのクライアントサーバーモード（ただしIISなし）で動作するはずです。だから私はその場合にWCFを使用しないでください？または他のオプション？
あなたはUserNamePasswordValidatorから継承し、このようにあなたの行動の設定でcustomUserNamePasswordValidatorTypeを設定することで、独自のバリデータを実装することができます。サービスのユーザー名/パスワードのプロパティ。
AuthenticationServiceを使用して、この解決策を確認してください。私はそれが好きとトライプラットフォームのアプリケーション（ウェブ/ SL/WPF）
http://msdn.microsoft.com/en-us/library/system.web.applicationservices.authenticationservice.aspx
は、サンプルの実装のためのリンクをたどるためにそれを使用することにしました。
このようにして、従来のカスタムASP .NET MembershipProvider実装（スタンドアロンクライアントの場合でも）に頼ることができます。
私はすでにAuthenticationServiceを見てきましたが、質問に記載されているように、私のアプリケーションの "未来"のバージョンで使えるのでしょうか？ –
従来の切断されたデスクトップアプリケーションでは、ASP .NET MembershipProviderを使用できますが、問題はありません。 – Jeff
HttpContextなしでASP.NET MembershipProviderを使用する方法？スタンドアロンWPFアプリケーションのように。 –
WCFを使用する利点は、ネットワーク内または外部にサービスを公開する場合、コードを変更せずにいくつかの追加の設定を変更または追加するだけで済みます。
クライアントとサーバーの両方を1台のマシンまたはネットワーク内に持つというシナリオでは、絶対に問題はありません。簡単な方法は、2つのエンドポイントを公開して、同じサービス上の要件を処理することです。
1つのエンドポイントでも回避できますが、異なるバインドメカニズムを使用して異なるエンドポイントを使用すると、認証時にオーバーヘッドが減少します。例：同じマシン上にいる場合は、net：pipeまたはnet：tcp bindingを使用できます。 ドメイン内にいるときは、net：tcpまたはhttpbindingを使用できます。
異なるバインディングを使用するとパフォーマンスが異なります。あなたはClientCredentials.UserNameにユーザー名/パスワードの組み合わせを設定することができ、クライアント側で
<behaviors>
<serviceBehaviors>
<behavior name="">
<serviceMetadata httpGetEnabled="true" />
<serviceCredentials>
<userNameAuthentication userNamePasswordValidationMode="Custom"
customUserNamePasswordValidatorType="MyNamespace.MyValidator, MyNamespace" />
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
：
似たようなものが必要でしたし、別の組み込みオプションを見直した後に、MessageInspector http://msdn.microsoft.com/en-us/library/aa717047.aspxを使うことにしました。これを使用することで、クライアントとサービス実装ロジックの外部のヘッダーにデータを注入できます。 – Michael