default.aspxでは3つの処理が行われる。default.aspxの実行にかかわるアカウントに関する情報の表示、アクセスログの記録、[管理ページ]ボタンの有効化である。
すでに解説したように、ASP.NETアプリケーションは3つのIDによって実行される。IISによって認証されたID、ASP.NET認証で認証されたID、ワーカープロセスの実行IDである。このうち、ASP.NET認証に認証されたIDは、Page.User.Identityプロパティから参照されるIIdentityオブジェクトを通して調べられる。また、ワーカープロセスの実行IDはWindowsIdentity.GetCurrentメソッドによって取得できるIIdentityオブジェクトを通して調べられる。default.aspxではこの2つのIIdentityオブジェクトのプロパティを一覧表示している。Page.User.IdentityプロパティにはWindows認証で認証されたIDの情報が、WindowsIdentity.GetCurrentメソッドで取得したオブジェクトにはアカウントASPNETの情報が格納されていることを確認できるはずだ。
なお、IISによる認証は基本的にASP.NETとは独立して行われるため、ASP.NETのコードからIISによって認証されたIDを直接調べる方法はない。ただし、Windows認証の場合は、IIS認証の結果がそのままWindows認証の結果として用いられるため、Page.User.Identityプロパティに格納されているIDがIIS認証の結果だと考えることができる。
以上2つのオブジェクトが持つpublicなプロパティを一覧する作業は、リスト18.5に示すコードによって行われている。ここではリフレクションと呼ばれる機能を利用して、IIdentityオブジェクトのプロパティ名とその値を取得し、データソースを作成している。あとはasp:DataGridコントロールにデータ連結すれば一覧表示される。
ICollection CreateDataSource(IIdentity identity) {
DataTable dt = new DataTable();
DataRow dr;
dt.Columns.Add(new DataColumn("property name", typeof(string)));
dt.Columns.Add(new DataColumn("value", typeof(string)));
Type t = identity.GetType();
PropertyInfo[] properties = t.GetProperties();
foreach (PropertyInfo pi in properties) {
dr = dt.NewRow();
dr[0] = pi.Name;
dr[1] = pi.GetValue(identity, null);
dt.Rows.Add(dr);
}
DataView dv = new DataView(dt);
return dv;
}
admin.aspxに設定したACLとファイル認定の働きによって、adminグループに所属していないユーザーからadmin.aspxへのアクセスは拒否される。これでも目的は達成されているとはいえるが、アクセスできないユーザーに対してもdefault.aspxに[管理ページ]ボタン(admin.aspxへのリンク)がクリックできる状態で表示されているのは好ましいことではない。そこで、アクセスできるユーザーに対してのみ、[管理ページ]ボタンをクリックできるようにする。
ボタン・コントロールでは、Enabledプロパティをtrueにすれば通常どおり、falseにすればグレイ表示されてクリックできないように表示される。よって、このプロパティをユーザーに応じて制御すればいい。リスト18.2のdefault.aspxでも記述しているように、ユーザーがadminグループに所属しているときにだけ[管理ページ]ボタンを有効化するには、以下のようにする。
if (User.IsInRole("aspserver\\admin")) {
admin.Enabled = true;
}
Windows認証によって認証されたユーザーが、特定のグループに所属しているかどうかを調べるには、IPrincipal.IsInRoleメソッドを利用する。前述したように、Windows認証の結果はPage.Userプロパティに格納されているので、パラメータに「<コンピュータ名>¥<グループ名>」または「<ドメイン名>¥<グループ名>」の書式でグループを指定して、User.IsInRoleメソッドを呼び出せば、指定したグループに所属しているか調べられる。
ファイル認定に参照されたり、IsInRoleメソッドに利用されたりするユーザーは、Windows認証によって認証されたユーザーだが、コードを実行するのは認証されたユーザーにかかわらずアカウントASPNETである。これはどういった処理で影響してくるのだろうか。
winauthアプリケーションでは、default.aspxがアクセスされるたびに、リスト18.6に示すコードによって、アクセスしたユーザーをファイルaccess.logに記録している。このコードによって、access.logが作成されたり、データが書き込まれたりするときは、アカウントASPNETによってACLチェックが行われるのである。
try {
string filename = Server.MapPath(".") + @"\access.log";
StreamWriter writer = new StreamWriter(
new FileStream(filename, FileMode.Append, FileAccess.Write));
writer.WriteLine(User.Identity.Name);
writer.Close();
}
catch (Exception ex) {
Message.Text = ex.Message;
}
つまり、access.logやファイルが作られるフォルダは、ASPNETが書き込める状態になければならないということだ。access.logは、default.aspxなどと同じアプリケーション・フォルダに作成されるので、このフォルダのACLを図18.9に示すように編集して、書き込み権を追加する。なお、こうしてフォルダに与えられたアクセス権は、そのフォルダ内に作成されるファイルにも継承されるため、access.logには自動的にASPNETの権利で書き込みできるように設定される。
今回は、IIS認証を活用して認証を行う、Windows認証を実装したWebアプリケーションのプログラミングについて見てきた。次回では、ログイン・ページと独自のユーザー・データベースを使用して認証を行う「フォーム認証」の実装について解説を行う予定だ。
Copyright© Digital Advantage Corp. All Rights Reserved.