問題タブ [principal]

WCFサービスクラスのコンストラクターで、現在のプリンシパルをメッセージのヘッダーで渡されたプリンシパルのプリンシパルに設定しています。

これは問題なく機能しているようですが、メソッドでプリンシパルを参照すると、Thread.CurrentPrincipalがWindowsPrincipalに戻りました。

おそらく、メソッドは別のスレッドで起動しています。メソッドがサービスのコンストラクターで設定されたプリンシパルを使用していることを確認するにはどうすればよいですか？

I want to be able to access custom properties for an authenticated user like UserId and FirstName without querying the database each time. I found this site through a post on Stack Overflow and I like the approach - but I use IoC / repositories and decided not to try and get global.asax to communicate with the database for fear that it would be incompatible with the repository pattern.

Instead, I created an interface to CustomPrincipal and I use IoC (Castle) to create an instance and pass it to the controllers (and subsequently to my base controller).

The base controller uses methods I created in CustomPrincipal to achieve the same task that the blog author addressed in global.asax. Namely, CustomPrincipal is initialized from the database or cache and assigned to HttpContext.Current.User.

My controllers/views can then reference the properties as follows...

It works, but I'm sensing some code smells. First and foremost, if I reference HttpContext from the controllers I've killed my unit testing. I'm thinking about modifying my CustomPrincipal object to return the above value (such that I can mock it in my unit tests) but I'm wondering if this is a workaround as opposed to a good solution.

Am I going about this the right way? Are there minor tweaks I could do to make it a robust solution or should I start from scratch with FormsAuthenticationTicket or something to that effect?

Thanks!

ビジネスレイヤーサーバーにWebフロントエンドがあります。

Web アプリケーションの特定のページは、非常に長時間実行されるタスクをインスタンス化します (最大で 10 分以上かかる場合があります)。これらのリクエストは次のように処理されます: -

(HTTP 要求スレッドで)

• ビジネスサーバーに接続します。
• 接続オブジェクトを渡す長時間の呼び出しを行う新しいスレッドを作成します。
• 次に、HTTP 要求が完了し、ハンドルがブラウザに返されます。
• ブラウザーは Web サーバーを定期的にポーリングして、実行時間の長いタスクの進行状況に関する最新情報を取得します。

ビジネス サーバーへのすべての要求は認証されます。接続のユーザー プリンシパル ページには、ビジネス サーバー上のメソッドを呼び出す権限が必要です。

このメカニズムは、Web アプリケーションがクラシック モードで実行されている限り正常に機能します。パイプライン モードで実行すると、ブラウザーのポーリング時に ObjectDisposedExceptions が発生します。

問題は、接続を確立するために使用された Windows プリンシパルが、元の要求が終了したときに破棄されることです (これは理解できます - 実際、コードがまったく機能したことに驚いています!)。

この問題を回避する方法として、HTTP リクエスト プリンシパルの複製を作成し、それを使用して接続を作成する (そして、長時間実行されるタスクが完了したら破棄する) ことが可能か、または、プリンシパルが破棄された後でも、ワーカー スレッドの HTTP 要求の原則は?

アップデート

(Aliostad の質問に対する私のコメントは間違っていました。テスト ページは失敗しました。実際の (障害のある) コードと同じコード パスを実行しないように、テスト ページを作成するのに十分な混乱をきたしました。気にしないでください!)

この問題の「回避策」を書きました: - ビジネス サーバーへの呼び出しが行われる前に、ビジネス サーバー ロジックがどのロール/グループを照会するかを知っている幸運な立場にあります。したがって、私の回避策は、これらのロールのリクエストのプリンシパルのメンバーシップに基づいて、新しい汎用プリンシパルを作成することです。長時間実行タスクは、汎用プリンシパルを使用して実行されます。

私はこの回避策に 100% 満足しているわけではありません。なぜなら、これは非常に「ハック」だからです。つまり、プリンシパルの ID が認証されていることを検証する (非常に賢明な) チェックを何らかのロジックで行うと、簡単に失敗することがわかります。

ですから、この問題についての助けや洞察をいただければ幸いです。

ありがとう

コマンドプロンプトで実行する簡単なコンソールアプリケーションは次のとおりです。

出力は「GenericPrincipal」であり、ID名として空の文字列です。なぜ実行時のGenericPrincipal代わりに構築するのWindowsPrincipalですか？WindowsPrincipal開始プロセス（私の場合はcmd.exe）のセキュリティトークンから構築するように強制するにはどうすればよいですか？

プラグインを個別の子アプリ ドメインにロードする必要があるアプリケーションを開発しています。1 つの子アプリ ドメインに読み込まれるプラグインは 1 つだけです。各プラグインには異なる Windows ID が必要であり、それらの ID は既定 (親) アプリ ドメインで使用される Windows ID とは異なります。各プラグインは、1 つ以上の子プラグインをロードします。

たとえば、既定のアプリ ドメインの ID はAuthority\Limitedです(権限はドメイン名またはマシン名のいずれかです)。2 つのプラグインが 2 つの子アプリ ドメインに読み込まれます。読み込まれたプラグインの ID は、Authority\Privileged1およびAuthority\Privileged2です。Authority\Privileged1とAuthority\Privileged2には、それぞれデータベースDatabase1とDatabase2へのすべての必要なアクセス権がありますが、 Authority\Limitedには前述のデータベースへのアクセス権はありません。

子アプリ ドメインを作成するときに、System.Security.Principal.WindowsPrincipalインスタンスを渡してSystem.AppDomain.SetThreadPrincipalメソッドを呼び出します。インスタンスは、複製されたユーザー トークンから作成されたSystem.Security.Principal.WindowsIdentityインスタンスから作成されました ( http://support.microsoft.com/kb/306158を参照)。WindowsIdentity.Impersonateメソッドの呼び出しを省略しました。これは、 WIndowsPrincipalインスタンスの作成中に既定のアプリ ドメインにいるためです。

アプリ ドメインのスレッド プリンシパルを設定するだけで、読み込まれたプラグインがそれぞれのデータベースに正常にログインし、いくつかの T-SQL ステートメントを実行できると予想していました。驚いたことに、WindowsIdentity.GetCurrent()メソッドによって返された値は、データベースへの接続を開くときに使用されます。メソッドによって返される値は、プロセス ID または偽装 ID のいずれかです。

プロセス ID には、データベースを操作するために必要なアクセス許可がないため、受け入れられません。したがって、なりすましが機能するようになる必要があります。ただし、偽装は子アプリ ドメインでのみ行う必要があります。各プラグインは、プラグインのロードとアンロードを実行するために使用されるメソッドを公開します。これらのメソッドの最初に偽装を実行し、最後に偽装を元に戻す必要があることを理解しています。ただし、子アプリ ドメインで生成されたすべてのスレッドに対しても偽装を行う必要があります。各プラグインは 1 つ以上の子プラグインをロードし、各プラグインは 1 つ以上のスレッドを生成する可能性があるため、多くの場所で偽装を実行する必要があり、非常に面倒です。

偽装を1 回だけ実行して、子アプリ ドメインで生成されたすべてのスレッドに影響を与えることはできますか?

名の部分を持つカスタム ユーザー詳細オブジェクトがあります。以下のユーザー名は機能しますが、2 番目のようなものが機能するようにしたいと考えています。このカスタム プロパティにアクセスするにはどうすればよいですか?

私はWCFで作業しており、に基づいた認証マネージャーを作成してIHttpModuleおり、正常に動作します。Authentication私のクラスの of メソッドの 1 つは、 にGenericPrincipalオブジェクトを作成しますContext.User。

例えば

のメソッドの 1 つでService、ユーザーを割り当てたいのですが、PrincipalPermissionAttributeどのように機能するかはわかりませんが、常にSecurityException. 例えば：

たぶんPrincipalPremissionAttribute使わないContext.Current.User？しかし、そうでない場合はどうなりますか？

問題を取り除き、非常に単純な属性を作成してみました

しかし、アプリケーションはこれを使用できません。つまり、コンストラクターにブレークポイントを設定するMyAttributeと、コンパイラーはビークポイントで停止せず、認識しません。

ゲームやグラフィックス業界での従来の物理シミュレーションは、基本的に離散的でした。しかし、box2dやbullet3dなどの最近のエンジンは、継続的な物理シミュレーションを実装しています。離散シミュレーションの基本原理は知っていますが、連続シミュレーションについてはわかりません。それは私にとって魔法であり、魔法を使うことは難しく危険です。ですから、魔法を理解して道具にしたいと思っています。

だから私は知りたいです：（1）これらの連続物理シミュレーションの基本的なアイデアと実装原理は何ですか？（2）アイデアを他の種類の離散シミュレーションに一般化できますか？これを理解させてください！

プログラムとサービス内で追加情報が必要なため、カスタム プリンシパルと ID タイプ (ProdigyPrincipal/ProdigyIdentity) を使用しています。プログラムでは、プリンシパルと ID を設定します。WCF サービスと通信する場合、プリンシパルと ID が設定されますが、独自の型にキャストした後、プリンシパルと ID は null になります。

デバッグ モードと単体テスト モードでの実行には違いがあることに気付きました。デバッグ モードでは、プリンシパルと ID の型はWindowsPrincipalとWindowsIdentityです。単体テスト モードでは、型は GenericPrincipal と GenericIdenity です。カスタム型にキャストする場合、どちらの場合も値は null です。

プリンシパル/ID の設定と取得は、Thread.CurrentPrincipalを介して行われます。バインディング セクションの App.configs で、セキュリティ モードが「トランスポート」に設定されています。

設定/プリンシパルと ID の取得に使用される関数:

カスタム プリンシパルと ID タイプをThreadから取得できない理由を知っている人はいますか?

敬具、ハンス

ケースは簡単です: ユーザーがログアウトをクリックし、LogoutFilter に移動して:

また、ページにログインリンクが表示されます。問題は簡単です。セッションは再作成されますが、ユーザー プリンシパルはキャッシュされるため、ログイン ポップアップは表示されず、アプリケーションはキャッシュされたプリンシパルを使用します。

質問は簡単です: ユーザー プリンシパルも削除する方法はありますか? そのため、ブラウザはログアウト後に再度ログインするよう求めますか?