ITmedia エンタープライズ

　これまでの説明を読んですでにお気づきのことと思われるが，IISではいかなる認証方式を用いる場合も，ドメインに登録されたユーザーアカウントで認証を実行する。そのため，IISの認証ユーザーを通常のアカウントと同じ方法で管理でき便利である半面，ドメインに登録されたユーザーアカウントはログオンして操作する何らかの権限を備えていることが多く，万一パスワードが漏洩した場合には，IISによるアクセス権限以外にも，さまざまなアクセス権限を与えてしまう危険性がある。

　Webアプリケーションで必要となる認証は，多くの場合，ユーザーが正しいアカウントとパスワードを指定したかどうかを調査する目的で利用される。入力されたユーザーアカウントがNTFSの読み取り権限を所持しているかどうかを調べたり，そのユーザーアカウントを使ってASPファイルや実行形式ファイルを実行させたり，という必要はないこともある。そのため，「該当するユーザーがドメインに登録されているかどうか」でユーザー認証を実現する必要性はなく，テキストファイルやデータベースに記録された，Webアプリケーション独自のアカウントデータベースを利用する方法でもかまわないことが大半である。もし，ドメインから独立したアカウントデータベースを利用してユーザー認証するのであれば，万一パスワードが漏洩したとしても，IISへのアクセス権限が与えられるだけであり，そのアカウント情報を使ってドメインにログインされてしまう危険性はない。

　そこで，ここでは簡単に，Webアプリケーション独自の認証方法を実装するにはどのようにすればよいのかについて説明する。

　Webアプリケーション独自の認証を実現する方法はいくつか考えられるが，一般には基本認証を用いる。基本認証の場合，クライアントからサーバーへの要求があると，サーバーはまず，ユーザー名とパスワードの入力が必要であることを告げるため，次のような応答コードならびにWWW-Authenticateヘッダ行を返す。

401 Access Denied
WWW-Authenticate: BASIC

　このような要求を受け取ったクライアントは，ユーザーに対してユーザー名とパスワードの入力を促すFig.8-63のようなダイアログボックスを表示する。そして，ユーザーが入力したユーザー名とパスワードを次のような形式のヘッダでサーバーに送信する。

Authorization: Basic ユーザー名:パスワード

　ただし，送信される「ユーザー名:パスワード」の部分は，Base64という形式でエンコードされる。

　したがって，サーバー側でAuthorizationヘッダを参照し，送られてきたユーザー名とパスワードの組み合わせと，Webアプリケーションで独自に用意しておいた認証用のアカウント情報とを比較し，両者が適合しているかどうかを調べれば，独自の認証を実現することができる。

　このような処理を実現するには，Response.Statusプロパティを使って“401 Access Denied”という応答行を返し，また，Response.ServerVariablesコレクションを使ってAuthorizationヘッダの情報を調べるという処理を実装すればよい。

　実際に独自の認証を実現するスクリプトの例を，List 8-30に示す。

　List 8-30は，Base64形式でエンコードされた文字列を復元する処理などがやや複雑であるため，ここでは詳細には立ち入らない。ただ，こういうプログラムを作れば，ASPで独自の認証を実現できるという点だけを理解していただければ十分である。より詳細について知りたければ，拙著『Windows NT 4.0 Webアプリケーション構築ガイド　Phase 2　IIS 4.0によるサーバーサイドプログラミング』を参照してほしい。なお，Base64形式とは，メール（MIME）などにも使われるエンコード方式であり，その仕様はRFC2045，RFC2046，RFC2047，RFC2048，RFC2049に記されている。

　List 8-30では，アクセス可能なユーザー名とパスワードの組み合わせを，31〜36行目で示したAllowUsersとAllowPasswordsという配列に格納している。しかし実際には，テキストファイルの内容を読み取ったり，リレーショナルデータベースに格納されたユーザー情報を取得したりして，それらとクライアントから送信されたユーザー名とパスワードの組み合わせが合致するかどうかを調べることになるだろう。

　なお，List 8-30のプログラムは，ディレクトリセキュリティの設定において，［匿名アクセス］のみにチェックを付けた仮想ディレクトリでしか正しく動作しない。なぜなら，ほかの認証方式にチェックを付けると，ユーザーが入力したユーザー名とパスワードをIISが先に処理してしまい，ドメインに登録されたユーザーと比較してしまうためである。

　すでに説明したように，［匿名アクセス］のみにチェックを付けた場合には，IUSR_サーバー名というアカウントによってASPファイルが実行される。よって，List 8-30のプログラムは，ユーザーが入力したユーザーアカウントではなく，常にIUSR_サーバー名というアカウントの権限で実行されることになる。