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 認証のログイン・ログオフ動作」と「非ドメインユーザーの誘導」に書きましたので興味がありましたら見てください。

IIS で基本認証を使用している場合、パスワードの変更をした後も、依然として古いパスワードが有効になる（すなわち、新旧パスワードのどちらでもログインできる）という話を書きます。

基本認証はあまり使われてないようなので、ここに書いたような問題に遭遇することはまれかもしれませんが、理由と対処方法を調べたので備忘録として書いておきます。

まず、理由ですが、Microsoft の TechNet の記事 IIS Insider の「パスワードの変更をした後も、依然として古いパスワードが有効となる」のセクションに書いてあるように、"ユーザーのログオン資格情報は、基本認証および匿名認証の両方で、IIS 上に 15 分間キャッシュされます" ということによります。

キャッシュするのはパフォーマンスの向上のためですが、何らかの事情でデフォルトの 15 分は長すぎるという場合は調整は可能です。

具体的には、Microsoft サポートの記事 IIS におけるユーザー トークンのデフォルトの間隔の変更 に書いてありますように、レジストリで変更することができます。

上の記事は IIS6 以下が対象ですが、ブログの記事 List of registry keys affecting IIS7 behavior の 3. 項によると、レジストリ UserTokenTTL の設定については IIS7 に関しても同じとのことです。

実際、IIS7.5 を使っているユーザーがレジストリに UserTokenTTL を新規登録（既存ではないとのこと）したところ、キャッシュの有効期限をコントロールできるようになったという報告があります。

ただし、一番上に紹介した記事に書いてありますように、"キャッシュが存在しない場合、すべてのアクセスで、認証を行う必要があり、パフォーマンスが大幅に低下する可能性があります" とのことですので、あまり短くするのは避けた方がよさそうです。

IIS の URL Rewrite モジュールを使用して aaaa/1/2/3 という URL を test.aspx?x=1&y=2&z=3 というように書き換えることを考えます。

この時、たとえば上の画像のように 2 つ目の値をスキップした aaaa/1//3 という URL を test.aspx?x=1&y=&z=3（y に値がないところに注目）に書き換えたい場合はどうすればいいでしょうか？

IIS7 の URL Rewrite モジュールを使って、普通に（というか、あまり深く考えずに）書換ルールを作ると以下のようにすると思います。

<rewrite>
  <rules>
    <rule name="DoubleSlash">
      <match url="aaaa/(.*)/(.*)/(.*)" />
      <action 
        type="Rewrite" 
        url="test.aspx?x={R:1}&y={R:2}&z={R:3}" />
    </rule>
  </rules>
</rewrite> 

IIS マネージャーの「テストパターン」ダイアログ上で、［テスト対象データの入力(D):］テキストボックスに aaaa/1/2/3 とか aaaa/1//3 などのテストパターンを入力してテストすると、 {R:1}, {R:2}, {R:3} には期待通りの結果が得られます。

なので、ブラウザから aaaa/1/2/3 とか aaaa/1//3 などで呼んでも同様に aaaa/(.*)/(.*)/(.*) にマッチして、test.aspx?x=1&y=2&z=3 とか test.aspx?x=1&y=&z=3 に書き換えられると期待すると思います。

しかし、ブラウザから aaaa/1//3 で呼ぶとダメです。ダメな理由は、IIS が aaaa/1//3 を aaaa/1/3 に書き換えてしまうからです。詳しく書くと以下の通りです。

1. ブラウザからは aaaa/1//3 で要求が出る。
2. それを受けた IIS は aaaa/1//3 を aaaa/1/3 に書き換えてしまう。
3. aaaa/1/3 が URL Rewrite モジュールに渡される。
4. aaaa/1/3 は aaaa/(.*)/(.*)/(.*) にはマッチしない。マッチしないので書き換えは行われない。
5. 書き換えが行われないので、IIS は aaaa/1/3 で指定されるリソースを探す。
6. そのようなリソースは存在しないので HTTP エラー 404.0 - Not Found となる。

ちなみに、aaaa/1/2/3 であれば期待通り test.aspx?x=1&y=2&z=3 に書き換えられ、test.aspx ページ内でクエリ文字列は正しく取得できます。

上記 2 がどうして分かったかと言うと、6 で表示されるエラー画面で「要求された URL　http://aspnet4site:80/aaaa/1/3」となっていたからです。（aspnet4site は自分の開発マシンで使っているホスト名です）

というわけで、上記 2 を何とかしないと URL Rewrite モジュールでは対処できないということになります。

それを何とかする手段が IIS Server Variables の UNENCODED_URL を使用して IIS が処理する前の URL を取得して、それに書換ルールを適用することです。

詳しい手順は Microsoft IIS.net の記事 URL Rewrite Module Configuration Reference の中の「Using server variables in rewrite rules」および「Using back-references in rewrite rules」というセクションが参考になると思います。

具体的な書換ルールのコードは、今回のケースでは以下のようになります。

<rewrite>
  <rules>
    <rule name="DoubleSlash">
      <match url="^aaaa/" />
      <action 
        type="Rewrite"
        url="test.aspx?x={C:1}&y={C:2}&z={C:3}" />
      <conditions>
        <add 
          input="{UNENCODED_URL}" 
          pattern="^/aaaa/(.*)/(.*)/(.*)" />
      </conditions>
    </rule>
  </rules>
</rewrite>

上記のルールで、aaaa/1/2/3 でも、aaaa/1//3 でも、aaaa//2/3 でも、 aaaa/// でも、その他全てのパターンで期待通り書き換えられるのを確認できました。