3

私はEntityFramework5で作業しています。ユーザー認証にMicrosoftActiveDirectoryを使用しています。適切なn層アーキテクチャを使用しているため、ほとんどの場合、ビジネス層はUIを幸いにも認識していません。

これで、完全な監査証跡を保持する必要があります。データベースで書き込み操作が発生するたびに、誰が変更を加えたかとともに、それを監査ログに保存する必要があります。

書き込みをキャッチするのは比較的簡単なはずです。SaveChanges()データコンテキストでオーバーライドし、を使用しObjectStateManagerてすべての挿入、更新、および削除を検索します。実際の問題は、現在のユーザーが誰であるかを検出することです。これは、認証がプレゼンテーション層で行われ、ビジネス層のDLLがIISでホストされ、任意の数のクライアントプロセスにサービスを提供するためです。

ビジネスレイヤー内で、クライアントによって使用された認証資格情報を検出する方法はありますか?APIのすべてのインターフェースにユーザーIDを渡す必要は絶対にありません!

(FWIW、私はEntityFramework.Extendedも使用しています。これは、ネイティブのAuditLog機能を備えていると思われますが、ドキュメントがひどく不十分です。これを正常に使用した経験のある人はいますか?)

4

2 に答える 2

3

認証を適切に構成した場合 (フォームまたは Windows 認証など)、Thread.CurrentPrincipal要求を行っているユーザーを参照することが保証されます。

于 2012-12-06T13:46:09.340 に答える
2

すべてのメソッドシグネチャに追加するのではなく、エンドユーザーのIDを帯域外に渡すことを検討できます。

たとえば、WCFを使用している場合は、クライアント側でカスタムSOAPヘッダーを挿入し、サーバー側でカスタムヘッダーを処理する動作を作成できます。

アップデート

質問へのコメントは、DLLがWebサービス経由ではなく、ASP.NETMVCアプリケーションから直接アクセスされていることを意味しているようです。私はあなたの声明から次のように仮定しました:

ビジネスレイヤーDLLはIISでホストされ、任意の数のクライアントプロセスにサービスを提供します

複数のASP.NETMVCアプリケーションから呼び出されたWebサービスであること。

ASP.NET MVCアプリケーションに含まれているDLLだけの場合は、非常に簡単です。

  • HttpContext.Current.User接続されたクライアントのIDが含まれます。

  • ビジネス層でHttpContextを使用するのではなく、それThread.CurrentPrincipalがと同じプリンシパルに設定されていることを確認する必要がありますHttpContext.Current.User

    ASP.NETを使用している場合RoleProvider、これは自動的に行われます。そうでない場合は、手動で行う必要があります。たとえば、global.asaxのAuthorizeRequestイベントハンドラーで行います。

次に、ビジネス層でエンドユーザーIDにとしてアクセスしますThread.CurrentPrincipal.Identity.Name

于 2012-12-06T13:38:28.423 に答える