1

Windows 認証を使用する WCF アプリケーションがあります。Windows プリンシパル オブジェクトは、System.Threading.Thread.CurrentPrincipal() プロパティで見つけることができます。それは大丈夫です。ただし、よりきめ細かい承認と監査に使用されるカスタム プリンシパル オブジェクトもあります。これは、Windows ユーザーではなく、ドメイン ユーザーです。私は本当に両方が必要で、サービス側でカスタム ユーザーを保存する場所を探しています。これにより、サービスで実行されるすべてのコードが、ビジネス レイヤーとデータ レイヤーを介してこのユーザーにアクセスできるようになります。

クライアントとサーバー間の通信は、カスタム動作とメッセージ インスペクターによって処理されます。クライアント (ASP.NET Web アプリケーション) からサービスを呼び出すと、現在のユーザーがセッションから取得され、サービス呼び出しでカスタム ヘッダーにシリアル化されます。サービス側では、ヘッダーからプリンシパルを取り除き、カスタム プリンシパルをここに配置します。

OperationContext.Current.ServiceSecurityContext.AuthorizationContext.Properties("CurrentDomainUser")

したがって、このアプローチを検証するための質問:

  1. これは、サービスにカスタム プリンシパルを保存するための有効なアプローチですか。Windows認証をそのままにしておきたいことを覚えておいてください。
  2. これは「ベストプラクティス」ですか？それとももっと良い方法がありますか？
  3. このアプローチで注意すべき落とし穴や落とし穴はありますか?

入力していただきありがとうございます。

4

1 に答える 1

2

これがベスト プラクティスであるかどうかは具体的にお答えできませんが、送信メッセージ ヘッダーでカスタム データを渡すことはできます。

クライアントから WCF サービスを呼び出す例を次に示します。

MyAccountService.MyAccountServiceClient client = new MyAccountServiceClient();
using (OperationContextScope scope = new OperationContextScope(client.InnerChannel))
{
    MessageHeader customHeader = MessageHeader.CreateHeader("customData", "ns", "My custom data");
    OperationContext.Current.OutgoingMessageHeaders.Add(customHeader);

    List<Bill> list = client.BillHistory("12345", DateTime.Now.AddMonths(-1), DateTime.Now);
}

サービス側では、受信メッセージ ヘッダーを検査できます。

public IList<Bill> BillHistory(string accountID, DateTime datefrom, DateTime dateTo)
{
    string customData = OperationContext.Current.IncomingMessageHeaders.GetHeader<string>("customData", "ns");
...etc...
}
于 2009-12-14T16:15:07.783 に答える