オフィスの上司は、開発者が次のことを行った Microsoft "Geneva" (現在の Windows Identity Foundation) のプレリリース バージョンのデモンストレーションを見たと言います。
彼は、カスタマイズされたログオン システムを使用してユーザーがログインできる、ある種の ASP.net Web アプリケーションをセットアップしました。バックグラウンドで、Web アプリケーションはユーザーを Active Directory のユーザーとしてログインさせます。
ユーザーがログインします。
ユーザーがログインすると、ASP.net Web アプリケーション スレッドは、ユーザーのセッション中にログイン ユーザーとして実行され、ネットワーク上のリソースにアクセスできます (アクセスが Active Directory で制御されているテーブルで SQL クエリを実行するなど)。
手順 2) と 3) は、IIS の Web サイト設定の [ディレクトリ セキュリティ] タブで [統合 Windows 認証] 設定を使用する場合とまったく同じです。ステップ 1) は、Kerberos 認証ではなくカスタム ログオン システムを使用しているため、異なります。
1)、2)、および 3) で説明したとおりに動作するように、アプリケーションの 1 つをセットアップしたいと考えています。ただし、私が見た Windows Identify Foundation に関するドキュメントはすべて、Cardspace と Federated Security に関するものです。現在、これらのテクノロジーのいずれかを使用することに関心はありません。
舞台裏でユーザーが Active Directory アカウントにログインできるようにしたいだけです。
ActiveDirectoryMembershipProviderはい、 withを試しましたForms Authenticationが、ネットワーク上のリソースに実際にアクセスするには、すべてのページで偽装が必要です。
更新 2010 年 1 月 7 日。わかりました、私はしばらくこれに取り組んできましたが、私がなんとか達成したことはすべて、私が達成したいことには達していません。おそらく、私が必要とする機能は、WIF のリリース バージョンには含まれていません。
ここが今いる場所です。MSDN で、ASP.net で使用される 3 つの異なる ID があることを示すドキュメントを見つけHttpContext.Current.UserましThread.CurrentPrincipalたWindowsIdentity.GetCurrent。 リンク
設計しようとしているプロセスを使用する場所の一例として、ログインしたユーザーとして SQL クエリを実行したいと考えています。私のデバッガーでは、HttpContext および Thread ユーザーをログイン ユーザーに簡単に設定できることがわかります。ただし、Windows 認証を使用して SQL サーバーに接続すると、常にユーザーとして接続され、WindowsIdentity.GetCurrent偽装で Windows 認証を使用していない限り、そのユーザーは常に ASP.net プロセスの ID になります。ユーザーは魔笛の曲を演奏してログインする必要があり、Windows 認証は魔笛の曲でのログインをサポートしていないため、アプリケーションで Windows 認証を使用することは絶対にできません。
明確にするためにWindowsIdentity、ログインしたユーザー (魔笛の歌でログインしたユーザー) を表す を取得することに問題はありません。WindowsIdentity問題は、それを使用してユーザーの SQL クエリを実行できないことです。