WebSurfer's Home

トップ > Blog 1   |   Login
Filter by APML

基本認証

by WebSurfer 23. November 2015 14:19

IIS7 で基本認証を行う際のブラウザとサーバーのやり取りを調べましたので備忘録として書いておきます。

基本認証のやり取り

上の画像は IIS7 と IE9 で基本認証を行った場合の要求 / 応答を Fiddler2 でキャプチャしたものです。

  1. 最初の要求に対してはサーバーから応答ヘッダに WWW-Authenticate: Basic realm="xxx" を含む HTTP 401 応答が返ってきます。上の画像の #2 がそれです。xxx には IIS7 の場合ホスト名が入ります。
  2. ブラウザはそれを受けてユーザーに[ユーザー名]と[パスワード]の入力を促すダイアログを表示します。
  3. ユーザーがダイアログに[ユーザー名]と[パスワード]を入力して[OK]ボタンをクリックすると、ブラウザは 1 で要求したページを再度 GET 要求します。上の画像の #3 がそれです。
  4. その際、ブラウザは認証用のヘッダ Authorization: Basic UGFwaWt...(上の画像で赤枠で囲った部分を見てください)をサーバーに送ります。UGFwaWt... の部分は[ユーザ名]と[パスワード]をコロン ":" でつなぎ Base64 でエンコードしたものです。
  5. サーバーはこのヘッダを見てユーザーを認証し、HTTP 200 ステータスコード(成功)と共に要求されたコンテンツをブラウザに送信します。
  6. これ以降、ユーザーがブラウザを閉じない限りホスト名 xxx に対しては認証用のヘッダ(画像で赤枠で囲ったものと同じ)が要求ヘッダに含まれて送信され、要求のたび自動的に認証が行われるようになります。上の画像の #4, #5 がそれです。

以上、基本認証でのブラウザとサーバーのやり取りを簡単にまとめてみました。

フォーム認証と Windows 認証の場合は、それぞれ先の記事「Forms 認証のログイン・ログオフ動作」と「非ドメインユーザーの誘導」に書きましたので興味がありましたら見てください。

Tags: ,

Authentication

パススルー認証

by WebSurfer 13. September 2015 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

非ドメインユーザーの誘導

by WebSurfer 9. July 2015 22:03

イントラネット内の Active Directory ドメイン環境で、統合 Windows 認証によってシングルサインオンが実現されているサイトがあって、そこに非ドメインユーザーがアクセスしてきたとき、そのユーザーを誘導する(例えば、ドメインユーザー専用である旨通知するとか、別のサイトにリダイレクトする)方法について書きます。(MSDN フォーラム の話をまとめたものです)

Windows 認証のやり取り

クライアントが Windows 認証サイトにアクセスしてくると、認証手続きが始まって、認証が成功し、要求したページが表示されるまで、上の画像(キャプチャツール Fiddler2 のもの。NTLM の場合)のように要求 / 応答がやり取りされます。

NTLM の場合、具体的には以下のステップ 1 ~ 9 のようになります。上の Fiddler2 の画像の左側のウィンドウのライン #1 がステップ 1 ~ 4、#2 がステップ 5 ~ 6、#3 がステップ 7 ~ 8 に該当します。

Kerberos の場合は NTLM より一回ラウンドトリップが少なくなります。以下のステップ 5 ~ 6 がないという感じです。(あくまで「感じ」です。詳しくは MSDN Blog の記事 Two easy ways to pick Kerberos from NTLM in an HTTP capture を見てください)

  1. ブラウザからページ(この例では Default.aspx)を GET 要求。
  2. サーバーは 401 応答を返す。その際、サーバー側で AuthenticateRequest, EndRequest イベント発生。イベントハンドラで User は null になる。
  3. クライアントには認証ダイアログが表示される。
  4. ユーザー名とパスワード入力して[OK]ボタンをクリック。
  5. ブラウザは再度 Default.aspx を GET 要求。
  6. サーバーは 401 応答を返す。この時はサーバー側で AuthenticateRequest, EndRequest イベントは発生しない。
  7. ブラウザは再々度 Default.aspx を GET 要求。
  8. サーバーは 200 応答を返す。サーバー側で AuthenticateRequest, EndRequest イベント発生。イベントハンドラで User はログインユーザーの WindowsPrincipal になる。
  9. ブラウザには Default.aspx が表示される。

統合 Windows 認証の場合、How IIS authenticates browser clients によると、認証済み / 未認証ユーザーの手続きの違いは、Kerberos でも NTLM でも、ステップ 3 ~ 4 の有無ということです。(自分の PC を立ち上げた時にドメインにログイン済みのユーザーの場合はステップ 3 はスキップ、ステップ 4 は自動的に行われる)

ステップ 3 でダイアログが表示された時、非ドメインユーザーができることは、[キャンセル]または[X]ボタンをクリックするか、3 回ユーザー名とパスワードを入力して認証に失敗するかですが、いずれの場合でも標準のエラーページが表示されます。

従って、アクセスしたサイトがドメインユーザー専用であることを説明するなどしたカスタムエラーページを作り、標準のエラーページと差し替えることによって、非ドメインユーザーを適切に誘導することができます。

自分の開発環境の IIS7 の場合ですが、applicationHost.config ファイルの httpErrors 要素に、カスタムページ ErrorPage.htm を以下のように設定することで差し替えることができます。

(注:自分の環境では applicationHost.config で httpErrors に対しては overrideModeDefault="Deny" と設定されているので web.config では httpErrors を設定できませんが、IIS7.5 では web.config で設定可能とのことです。ご自分の環境で確認ください)

<location path="Default Web Site/WindowsAuthentication">
  <system.webServer>
    <httpErrors errorMode="Custom">
      <remove statusCode="401" />
      <error statusCode="401" 
        path="C:\inetpub\custerr\ja-JP\ErrorPage.htm"
        responseMode="File" />
    </httpErrors>
  </system.webServer>
</location>

認証ダイアログが表示された直後に[キャンセル]または[X]ボタンをクリックした場合は、差し替えたカスタムエラーページが表示されます。

しかし、自分の環境で試した限りですが、一旦認証ダイアログに ID / パスワードを入力して認証に失敗した後に返ってくるエラーページは最初の標準エラーページとは異なり、これをカスタムエラーページに差し替えることはではできませんでした。

(注:IIS7.5 ではカスタムエラーページに差し替えられたとの報告があります。その場合は以下の対応は不要となります。ご自分の環境で確認ください)

その場合、EndRequest イベントで User.Identity.IsAuthenticated が true、Response.StatusCode が 401 になることで判定でき、以下のようにすることにより対応できます。ステップ 5 ~ 6 ではイベントは発生しないのでこのやり方でうまくいきます。

void Application_EndRequest(object sender, EventArgs e)
{
  if (User != null)
  {
    bool auth = User.Identity.IsAuthenticated;
    int statusCode = Response.StatusCode;

    if (auth && statusCode == 401)
    {
      HttpContext.Current.Response.Redirect("リダイレクト先");
    }
  }
}

ちなみに正しい ID / パスワードが入力され認証に成功した場合は Response.StatusCode が 200 になりますので、リダイレクトされてしまうということはありません。

ユーザー名とパスワードを入力するダイアログが表示されるのは避けられないとうところが難ありですが、それでよければ上記の案で非ドメインユーザーを適切に誘導することができそうです。興味があればお試しください。

なお、統合 Windows 認証は IE2 以降でのみサポートされているということなので(参考:認証について)、User Agent を調べてブラウザが IE 以外なら即リダイレクト等の処置をとってもいいかもしれません。

Tags: ,

Authentication

About this blog

2010年5月にこのブログを立ち上げました。その後 ブログ2 を追加し、ここは ASP.NET 関係のトピックス、ブログ2はそれ以外のトピックスに分けました。

Calendar

<<  February 2020  >>
MoTuWeThFrSaSu
272829303112
3456789
10111213141516
17181920212223
2425262728291
2345678

View posts in large calendar