WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

パススルー認証

by WebSurfer 2015年9月13日 16:29

IIS マネージャーで[サイトの編集]を行う際、下の画像(Vista の IIS7 のものです)のように「パススルー認証」という言葉が出てきますが、これは一体何かという話を書きます。

パススルー認証

まず、そもそもパススルー認証とは一般的にどういう意味かですが広義には以下のようなことらしいです。

例えば、サーバー A とサーバー B の 2 つのサーバーがあり、サーバー B のみにユーザーの資格情報が保持されているとします。

クライアントがサーバー A にアクセスした際、サーバー A ではユーザー認証ができないので、サーバー A はサーバー B にユーザー認証を要求します。そのようなメカニズムをパススルー認証 (Pass-Through Authentication) と呼んでいるそうです。

MSDN の記事 Pass-Through Authentication の Figure 1 を見て、Active Directory ドメインサービス環境で統合 Windows 認証を使用している場合を考えると理解しやすいかもしれません。

で、それと上の画像の「パススルー認証」とどういう関係があるのかですが、それについては「サイトの編集」ダイアログのヘルプ(右上の ? ボタンをクリックすると表示される)に以下の説明があります。

"必要に応じて、[接続] をクリックして、物理パスに接続するための資格情報を指定することもできます。 資格情報を指定しない場合、Web サーバーはパススルー認証を使用します。 これは、コンテンツにはアプリケーション ユーザーの ID を使用してアクセスし、構成ファイルにはアプリケーション プールの ID を使用してアクセスすることを意味します。"

注意 1:
上で「コンテンツにはアプリケーション ユーザーの ID を使用」とありますが、これは統合 Windows 認証の環境でパススルー認証によってユーザー認証が完了した場合で、匿名認証の場合は IUSR が使用されます。また、「コンテンツ」というのは静的コンテンツのみです。(動的コンテンツについては下の注意 3 参照)

注意 2:
上で言う「構成ファイル」とは web.config のことです。物理パス C:\inetpub\wwwroot には自動的にアプリケーションプール ID が適切なアクセス権を持つように設定されます(正確には、Microsoft TechNet の記事 に書いてあるように、wwwroot フォルダに対して必要なアクセス権を持つ IIS_IUSRS グループが設定されます。そして、実行時にアプリケーションプール ID のアクセストークンに対して IIS_IUSRS メンバーシップが自動的に追加されるので web.config には問題なくアクセスできます)。

ただし、物理パスが C:\inetpub\wwwroot 以外にある場合は要注意です。特に、物理パスが UNC にあって web.config も UNC にある場合がややこしいです(詳しくは Microsoft Support の記事 を見てください)。

注意 3:
.aspx, .ascx などの動的コンテンツへのアクセス、.aspx.cs, .ascx.cs などコードビハインドのコードでのファイルや SQL Server へのアクセスは「アプリケーション プールの ID を使用」します。

この場合、先の記事 で書きましたように Temporary ASP.NET Files フォルダーにコンパイル済みアセンブリが置かれますので、アプリケーション プールの ID はそのフォルダに対しても適切なアクセス権を持つ必要があります。(自動的に設定されているはず)

なお、.aspx ページの中に外部スクリプトファイルや外部 CSS ファイルなど静的ファイルを取り込むための定義(例: <script src="/scripts/jquery.js" ...)がされていて、.aspx ページがブラウザに読み込まれた後、ブラウザがそれらの静的ファイルをサーバーに要求した場合は、上で言う「コンテンツにはアプリケーション ユーザーの ID を使用」が当てはまりますので注意してください。ただし、HTTP ハンドラ経由で静的ファイルを取得する場合(例:HTTP ハンドラでキャッシュコントロール)は話は別で「アプリケーション プールの ID を使用」します。

さらに、「サイトの編集」ダイアログ上の [接続] をクリックすると表示される「接続」ダイアログのヘルプには [アプリケーション ユーザー (パススルー認証)] に対して以下の説明がされています。

"このオプションは、パススルー認証を使用する場合に選択します。 このオプションを選択すると、物理パスへのアクセスに要求元のユーザーの資格情報が使用されます。

匿名要求については、匿名認証用に構成されている ID が物理パスへのアクセスに使用されます。 既定では、この ID は組み込みの IUSR アカウントです。

認証された要求の場合、物理パスへのアクセスに要求元のユーザーの認証済み資格情報のセットが使用されます。 このアプリケーションで使用されるアプリケーション プール ID は物理パスに対して読み取りアクセス権を持ち、認証されたユーザーが、物理パス上のコンテンツにアクセスできるようにします。"

・・・という訳で、「接続」ダイアログのパス資格情報で [アプリケーション ユーザー (パススルー認証)] を選択するということは、

  1. 匿名アクセスの場合は IUSR、(デフォルト。IUSR は変更可能
  2. Winsows 認証の場合はログインしたユーザーの Windows アカウント、
  3. Forms 認証でユーザーがログイン済みの場合の場合アプリケーションプール ID(例:IIS7 では NETWORK SERVICE。ASP.NET の ID オブジェクト 参照)

の資格情報で「サイトの編集」ダイアログで [物理パス(P):] に設定したパスのコンテンツにアクセスすることになり、統合 Windows 認証を利用している場合は上に述べたパススルー認証のメカニズムによってユーザーの資格情報をドメインコントローラーから取得してコンテンツにアクセスすることになるはずです。

従って、通常は IIS のデフォルトの設定どおりパススルー認証としておけば、統合 Windows 認証に限らずほとんどのケースで問題なさそうです。

なお、「サイトの設定」ダイアログで [テスト設定(G):] をクリックすると、「テスト接続」ダイアログに [結果(R):] が 2 つ表示され、前者は OK ながら、後者の方に "パス (C:\xxx\yyy) へのアクセスを検証できません。" と表示されて問題ありそうな感じがしますが、それは気にしなくてよさそうです。

テスト接続

前者は ( ) 内に示す ID が有効かどうか、後者はパススルー認証で物理パスへのアクセス権があるかどうかの結果を表示しているようですが、IIS マネージャーが検証できないだけで、実際にアクセス権がないと言っているわけではなさそうですので。

------------

ところで、一番上の画像の「接続」ダイアログで [特定のユーザー(U):] を指定した場合ですが、それついてはまだよく分かってないです。(汗)

物理パスへのアクセスが指定したユーザーのアクセス権で行われるのは間違いなさそうです。

ただし、特定のユーザーを指定することによって、web.config にそのユーザーの偽装が設定されるとか、匿名アクセスの資格情報が IUSR から変更になるということはなかったです。

また、フォーム認証でのログイン操作の際に "System.Data.SqlClient.SqlException: ユーザーにはこの操作を実行する権限がありません。" というエラーが出てログインできなくなるという問題が出るなど、訳がわからないところもあります(App_Data の ASPNETDB.mdf へのユーザーインスタンスへの接続ですが、資格情報の問題ではなさそう。他の DB のユーザーインスタンスには接続できたので)。

今後の課題ということで、分かったらまたこの記事に追記することにします。

Tags: ,

Authentication

ReportViewer と Session

by WebSurfer 2015年9月7日 15:22

ReportViewer は Session を使うという話を書きます。

IE で ReportViewer を表示

上の画像は、ReportViewer を使用してパラメーターを含む詳細 (RDLC) レポートを作成する というチュートリアルに従って作ったものですが、どこにも明示的に Session を使うようなコードは含まれていません。

ところが、このページを要求すると、下の画像(Fiddler2 でキャプチャしたもの)のように応答ヘッダにセッション Cookie が設定され(画像の赤枠で囲った部分)、Session の使用が開始されます。

応答ヘッダのセッション Cookie

知ってました? 実は自分は知らなかったです。(汗) 最近まで ReportViewer と Session は何の関係もないと思っていましたが、MSDN フォーラム でのやり取りを通じてこのことを知りました。

MSDN Blog の記事 Did Your Session Really Expire? によると、ReportViewer は再生するのが簡単ではないデータを保存するのに Session を使うとのことです。

そして、ポストバックの際などに期待したデータが Session にないと AspNetSessionExpiredException をスローするとのことです。

AspNetSessionExpiredException 例外がスローされる原因として次のことが書かれています:

  1. 本当にセッションがタイムアウトした。(例:ping をかけてタイムアウトにならないようにしているが、サーバーが忙しいとか接続が不安定で失敗した)
  2. 要求を処理しているサーバーにセッションがない。(例:セッションのモードが InProc で、Web Garden / Farm 構成になっているとか、ワーカープロセスがリサイクルされた)
  3. ブラウザがクッキーを受け付けない設定になっている。

上記 1 のことは MSDN ライブラリの ReportViewer.KeepSessionAlive プロパティ に書かれています。デフォルトは true で、セッションがタイムアウトしないように自動的に ping がかかります。

上記 2 のワーカープロセスのリサイクルによる Session の消失を防ぐためには、Session の格納場所を InProc ではなく、StateServer または SQLServer にするのがよさそうです。商用に使うのであれば、InProc モードは論外という意見もあるようですし。設定方法の詳細は MSDN ライブラリの記事 セッション状態モード を見てください。

Tags: ,

ASP.NET

IE でアップロードする際のファイル名

by WebSurfer 2015年8月6日 11:52

Internet Explorer (IE) でファイルをアップロードする際、ファイル名にフルパスが付与されることがあります。

IE のセキュリティ設定

上の画像は IE9 のローカルイントラネットゾーンのセキュリティ設定ですが、赤枠で囲んだ部分が示すように、デフォルトで [有効にする] が選択されており、送信データの Content-Disposition: ... filename="xxx" の xxx はフルパスになります。

インターネットゾーンでも IE7 以前はデフォルトで [有効にする] が選択されているそうです(未確認です)。ちなみに IE9 ではデフォルトで [無効にする] が選択されているのは確認しました。

知ってました? 実は自分は最近まで知らなかったです。(汗) 調べていませんが、他のブラウザでも同様な問題があるかもしれません。

今までその問題に遭遇したことはなかったのですが、それはファイル名の取得に FileUpload.FileName プロパティ を使っていたので、問題を免れていたと言うことのようです。

上のリンク先の MSDN ライブラリの「解説」に、"FileUpload コントロールを使用して、アップロードする、クライアント上のファイルの名前を取得します。FileName プロパティが返すファイル名には、クライアント上のファイルのパスが含まれません。" と書いてありますね。

ちなみに、HttpPostedFile.FileName プロパティ では、ブラウザからフルパスでファイル名が送信されてくれば、結果はフルパスになります。

なので、HttpPostedFile.FileName プロパティを使わざるを得ない場合は(複数ファイルを同時アップロードするような場合が該当するでしょうか)、Path.GetFileName メソッド を使ってファイル名を取得するのがよさそうです。

そういえば、昔ネット上で見かけてサンプルコードに Path.GetFileName メソッドを使った例が多々あったような記憶があります。

Tags: ,

Upload Download

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年3月  >>
252627282912
3456789
10111213141516
17181920212223
24252627282930
31123456

View posts in large calendar