第17回　ASP.NETにおける認証と認定：連載プログラミングASP.NET　―ASP.NETによるWebアプリケーション実践開発講座―　（2/3 ページ）

» 2003年05月17日 00時00分公開

認定（Authorization）

　認証さえ通過してしまえば、どんなIDでもアプリケーションの機能を共通に利用できるというのであれば、認証によってユーザーからのアクセスをコントロールするだけで十分だが、多くの場合そうではないだろう。例えば、認証されたID名が「admin」であったら管理用ページへのアクセスを許可するなど、IDに応じて特別な許可を与えるプロセスが必要となるはずだ。こういった、要求されたアクセスに対して許可を与えるかどうかを、IDに応じて判断するプロセスが認定（Authorization）である。

■ファイル認定とURL認定

　ASP.NETには、基本的な認定プロセスを提供するために、2種類のサービスが用意されている。

　1つはWindows認証を使用しているときにだけ利用できるファイル認定である。ファイル認定は、Windows認証を選択すると自動的に有効化され、ファイルへアクセスする前にACL（アクセスを許可されたユーザー・アカウントとグループの一覧）がチェックされることによって行われる。もし特定のユーザーしかアクセスできないASP.NETページ「admin.aspx」を提供したければ、ローカル・システム上でのアクセス制御と同じように、admin.aspxのACLを編集すればいい（図17.6）。ファイル認定のためにweb.configを設定したり、コードを追加したりする必要はない。

図17.6　ASP.NETページ「admin.aspx」のACL
必要なアカウントにだけこのページへのアクセス権を与える。ただし、アカウント「ASPNET」に読み出し権は必須（Windows Server 2003のIIS 6.0では「Network Service」。いずれもデフォルト値の場合）。

　もう1つは、認証方式によらず利用できるURL認定である。URL認定はURLを基準にアクセス制御を行う認定サービスだが、指定方法は違えどASP.NETページファイルに対するアクセスを認定するという点ではファイル認定と変わらない。

　URL認定は、アプリケーション・フォルダに配置したweb.configにauthorization要素を記述することによって設定する。authorization要素に設定した内容は、web.configが格納されたディレクトリと、そのサブディレクトリにあるすべてのASP.NETページに適用される。ただし、サブディレクトリに別のweb.configが格納されていた場合は、そちらの内容が優先される。

　authorization要素では、allow要素（許可を与える）とdeny要素（拒否する）を使って、ユーザー単位の認定ルールを指定できる。例えば、以下のように設定すれば、ユーザーuser1にはアクセスを許可し、それ以外のすべてのユーザーからのアクセス（“＊”で表現する）は拒否するようになる。同じユーザーが複数のallow要素とdeny要素にマッチする場合は、先に記述された方が優先される。

　もしauthorization要素に何も指定しなかった場合は、暗黙の認定ルール「<allow users="*" />」が適用されるため、認証されていないユーザーも含め、すべてのユーザーにアクセスが許可されてしまう。フォーム認証で非認証ユーザーからのアクセスを拒否するには、最低限以下の認定ルールを記述しなければならない。

　users属性で指定された“？”は非認証ユーザーを表す特別な記号である。Windows認証の場合は、匿名アクセスのまま認証プロセスを通過してくることはまずないので、必ずしも必要な設定ではないが、何かしらミスによって匿名アクセスが許可されてしまったときに備えて記述しておくといいだろう。

　またURL認定では、roles属性を指定して、ロールベースのアクセス制御を行うことも可能だ。ロールとは何らかの権利を持ったIDの集合である。ロールの実体は認証方式によって異なり、Windows認証ならば認証されたユーザーが所属するグループをロールとして参照できる。この場合グループは“＜コンピュータ名＞\＜グループ名＞”または“＜ドメイン名＞\＜グループ名＞”として参照され、以下のようにしてロールを指定する。この例ならば、“DomainName\SampleGroup”に所属するユーザーだけにアプリケーションへのアクセスが許可されるようになる。

　一方、フォーム認証でも以下のようにロールベースのURL認定を利用できるが、Windows認証のようにデフォルトでIDに対応するロールというものは存在しない。IDの管理がアプリケーションに任されているため、IDとロールの対応もアプリケーションで実装しなければならないのである。それなりの処理を行わなければ、前述したweb.configにIDを登録する方法では、ロールを利用することはできない（以下のような記述はできない）。フォーム認証でロールを利用する方法については、次回で詳しくは解説する。

　以上のように、ページへのアクセス制御を行うために2種類の認定プロセスが提供されているわけだが、IDやロールに応じてより細かな制御を行いたければ、コードで実装することになる。

■認定とアクセス制御

　ここまでに2つの認定サービスを解説したが、ここで認定の対象となるIDとはなんだろうか。いうまでもなく、それはWindows認証あるいはフォーム認証で認証されたIDだ。それでは、このIDが認定されさえすれば、アプリケーションを構成するすべてのファイルへアクセスできるのかというと、そうではない。

　まず第一に、ASP.NETの認定サービスは.aspxファイルや.asaxファイルなど、ASP.NET関連のファイルに対してのみ機能するということを理解しておく必要がある。より正確には、ASP.NETを処理するISAPIエクステンションであるaspnet_isapi.dllがマップされた拡張子のファイルのみが、認定プロセスの対象となる。つまり、JPEGファイルやHTMLファイルなどは認定の対象外なのである。

　するとどういうことになるか。例えば、フォーム認証とURL認定を組み合わせて、非認証ユーザーのアクセスを拒否していたとしよう。こうすればASP.NETページ（*.aspx）へのアクセスは制限できる。しかし、JPEGファイルなどについては、直接URLを指定することでアクセスできてしまうのである。認証されていないユーザーからのアクセスであっても、ログイン・ページへ強制的にリダイレクトされることもない。認定対象外のファイルについては、ごく通常のアクセス制御しか行われないためだ。つまり、IISマネージャで匿名アクセスを許していればIUSR_＜コンピュータ名＞で、あるいは基本認証や統合Windows認証で認証されていれば認証ユーザーの権限で、アクセスされてしまうのである。

　ただ、これが問題になるのはフォーム認証を利用しているときだけで、Windows認証ならば問題はない。Windows認証ではIISによって認証されたIDがそのまま認定にも利用されるため、IISによるアクセス制御と、ASP.NETの認定プロセスで使われるIDが必ず一致するからだ。従って、.aspxページにはアクセスできなくても、JPEGファイルにはアクセスできる、などということは起こらない。

　第二に、認定プロセスの対象となるファイルは、認定と同時に、ファイル・システムによるACLチェックも行われるということを忘れてはならない。このチェックは、ASP.NET認証ともIIS認証とも関係なく、アカウントASPNETによって行われる（デフォルト設定の場合）。このアカウントASPNETは、machine.confで設定されている、ASP.NETを処理するワーカープロセスのデフォルト実行ユーザーである（注意：Windows Server 2003に搭載されるIIS 6.0では「Network Service」に変更されている）。ワーカープロセスはアカウントASPNETに関連づけられたアクセス・トークン（アカウントの識別情報）によって.aspxファイルなどを読み出すため、このときのACLチェックもパスしないと、アクセスできないのである。なお、これはASP.NETの認定プロセスと同じく、aspnet_isapi.dllがマップされたファイルだけに限られた話で、JPEGファイルなどならばASPNETへの許可は不要である。

　以上のように認証～認定の流れはファイルタイプが影響するなど少々複雑なので、Windows認証とフォーム認証を利用したとき、それぞれでアクセスが許可されるまでに通過しなければならない認証と認定プロセスを以下にまとめておく。

■Windows認証（匿名アクセス拒否を前提）

1． IISによる認証。同時にWindows認証

　.aspxファイルなど（aspnet_isapi.dllにマップされたファイルタイプ）

　　2-A．アカウントASPNETによるACLチェック

　　3-A．ファイル認定

　　4-A．URL認定

　JPEGファイルなど

　　2-B．IISによって認証されたIDによるACLチェック

■フォーム認証（匿名アクセス許可を前提）

　.aspxファイルなど（aspnet_isapi.dllにマップされたファイルタイプ）

　　1．フォーム認証