2

基本認証、カスタムサービスホスト、およびを使用するRESTfulWCFサービスがあります。カスタムUserNamePasswordValidatorを設定しましたが、カスタムIPrincipalが正しく操作に流れます。ただし、従来の相互運用性のために、別の認証モードをサポートする必要があります。それが機能する方法は次のとおりです。

  1. ログインURIへのユーザーPOST
  2. サービスは上記のようにユーザーを認証しますが、HTTP応答ヘッダーとしてセッショントークン（暗号化されたユーザー資格情報）を返します。
  3. ユーザーからの後続のすべての要求には、基本認証の代わりにセッショントークンが含まれます。

私の現在の考えはこれです：セッショントークンに暗号化された資格情報が含まれている場合、着信メッセージを操作し、資格情報を復号化し、セッションヘッダーを基本認証ヘッダーに置き換えることができるはずです。私の問題は、次のような拡張ポイントを見つけることです。

  • 何らかの方法でメッセージプロパティを公開し、
  • カスタムUserNamePasswordValidatorが実行される前に実行されます。

そのような拡張性のポイント、またはトランスポートセキュリティメカニズムをカスタマイズする方法を知っている教祖はいますか？私はここにある膨大な数のオプションに正直に戸惑っています。ReflectorでSystem.ServiceModel名前空間を閲覧することは、フラストレーションのたまりでした。

ありがとう！

4

1 に答える 1

2

私は自分で答えを見つけました。答えは、質問で概説されている正確なメカニズムを実装する方法、つまりパスワード検証の前にHTTPヘッダーを別のヘッダーに置き換える方法を理解できなかったということです。

代わりに、UserNamePasswordValidatorをIAuthorizationPolicyに置き換えました。ポリシーのEvaluateメソッド内で、別のクラスが基本クレデンシャルまたはセッションキーのいずれかのチェックを処理し、カスタムIIdentityを返します。ここで重要なのは、認証が成功すると、カスタムIDを含む新しいリストがevaulationContextの「Identities」プロパティに追加され、カスタムプリンシパルが「Principal」プロパティに追加されることです。これらのプロパティが設定されると、WCFはプリンシパルをオペレーションに正しくフロースルーします。

これは満足のいく解決策であることが証明されていますが、私が探していた拡張ポイントを見つけられなかったことにはまだ失望しています。

于 2010-08-26T04:17:09.437 に答える