第17回 ASP.NETにおける認証と認定：連載 プログラミングASP.NET ―ASP.NETによるWebアプリケーション実践開発講座― （1/3 ページ）
Webアプリのセキュリティ確保は非常に面倒な問題だが、ASP.NETには数少ない手順でこれを実現するための仕組みが用意されている。
Back Issue
認証（Authentication）
会員専用ページや、サイトの構成を行うための管理者向けページのように、あるページを何か特別な権利を持ったユーザーにだけ公開するには、ユーザーがアクセス権を所有するユーザー本人であるか、確認するプロセスが必要となる。このプロセスが認証（Authentication）である。認証の方法はさまざまだが、ご存じのとおりユーザー名とパスワードのペアを用いて行われるのが一般的だ。
認証を必要とするアプリケーションを構築するには、ユーザーの資格情報を管理する仕組みと、未認証のユーザーに認証を求める仕組み、それに認証済みのIDを検証する仕組みが必要になる。これらをすべて独自に実装するのは骨の折れる仕事だが、ASP.NETではいずれについてもフレームワークからの支援が受けられるので、場合によっては、ほとんどコードを書かずに認証プロセスを実現することが可能だ。もしフレームワークによる支援だけでは不足だというのであれば、必要に応じてカスタマイズされた認証プロセスを実装し、拡張することも難しくはない。
ASP.NETでは基本的な認証プロセスが3種類提供されている（表17.1）。IISによる認証を活用するWindows認証、ログイン・ページと独自のユーザー・データベースを使うフォーム認証、それにPassportサービスを利用してシングル・サインオンを実現するPassport認証である。
| 認証プロセス | 内容 |
|---|---|
| Windows認証 | IISの認証プロセスをASP.NETから利用する |
| フォーム認証 | フォームを使った独自の認証プロセスを実装する |
| Passport認証 | Passportサービスを使ってシングル・サインオンを実現する |
| 表17.1 ASP.NETが提供する3種類の認証プロセス | |
今回はこの中からWindows認証とフォーム認証について解説していく。
■Windows認証
Windows認証の利点は何といってもその簡便さにある。なにしろ、認証にかかわるコードをまったく記述することなく、認証プロセスを実現することもできるのである。
Windows認証では、WindowsのSAM（Security Account Manager）データベースに登録されたユーザー・アカウントをそのままASP.NETアプリケーションの認証に用いるため、独自にユーザー管理の仕組みを実装する必要がなくなる。
それに、ユーザーが認証を受ける一連の仕組みについても、IISに実装されている認証プロトコル（基本認証、ダイジェスト認証、Windows統合認証）が利用されるため、ASP.NETページへのアクセスが発生したときには、すでに認証を終えた状態になっている（図17.1、図17.2）。
図17.1 Windows認証の仕組み
Windows認証では、IISによる認証プロセスがアプリケーションの認証に利用される。このため基本的な認証プロセスであれば、アプリケーション・コードで実装する必要はない。
図17.2 認証ダイアログボックス
Windows認証ではHTTPとして実装されている認証方式が利用されるため、ブラウザによって表示されるダイアログボックスで資格情報を入力する。また統合Windows認証を利用する場合は、認証を意識させないシームレスなアクセスが可能になる。
さらに、リソースへのアクセスがIISによって認証されたユーザーの権限で行われるように構成できるため、アクセス制御のコードも最小限で済ませられる。例えば、ファイル・システムへのアクセスであれば、フォルダやファイルのアクセス制御を適切に設定することで、認証を受けたユーザーの中でも特別なユーザーにだけアクセスを許す、といった細かな制御か可能になる（図17.3）。
図17.3 アクセス制御を設定するためのファイル・プロパティ
Windows認証ではASP.NETアプリケーションとWindowsの認証システムが統合されるため、アクセス制御にもACL（Access Control List：アクセス制御リスト）などのWindowsのオブジェクトが利用される。
認証にしろ、アクセス制御にしろ、いずれもWindowsとIISによってコントロールされるため、アプリケーションはいまアクセスしているユーザーが認証を受けているのかどうかさえ意識せずにすますこともできる。
ただし、ASP.NETアプリケーションのためだけにWindowsシステムにアカウントを作るのは、明らかにセキュリティ上好ましいことではない。正しく構成しなければ余計な権利が発生して、そのアカウントでほかのWindowsサービスへもアクセスできてしまうかもしれないからだ。従って、Windows認証は、主にイントラネット・ユーザー向けのWebアプリケーションで利用することになるだろう。
■フォーム認証
Windows認証は、Windowsシステムと統合されたIISに認証を任せることによって、ほとんどの認証プロセスをアプリケーションから取り除けるのが特徴だが、組織外部のユーザーに公開するアプリケーションであれば、統合された認証システムは好ましいものではない。そこで、Windows認証には頼らず、アプリケーションが独自のユーザー・アカウントを管理するための仕組みとして提供されているのがフォーム認証である。
フォーム認証ではIISの認証システムは利用しないため（通常IIS認証は匿名アクセス許可に設定する）、認証用のログイン・ページを用意し、認証の成否を判断したり、ユーザー・アカウントを管理したりするための、Windows認証ではIISが担当していた認証プロセスのほとんどをアプリケーション側で実装しなければならない。ただ、いずれにしてもASP.NETによる支援があるため、ASP.NETページとしてログイン・ページを用意して（図17.4）、わずか数行のコードを記述するだけでもフォーム認証を利用可能だ。
Windows認証に比べるとアプリケーションの負担が大きいフォーム認証だが、アクセスに使われたIDを検証し、必要であればログイン・ページへとリダイレクトする仕組みはASP.NETに任せることができる（図17.5）。おかげで各ページに認証をチェックするコードを含めるような手間は不要だ。
図17.5 フォーム認証の仕組み
フォーム認証が有効化されたアプリケーションがアクセスされるとチケット（認証済みのIDを表すクッキー）が確認される。チケットが存在しなければ、そのIDは認証されていないと判断され、あらかじめ設定されたログイン・ページのURLへとリダイレクトされる。
以上のようにIDの検証は暗黙的に行われるため、フォーム認証を使うアプリケーションでは、最低限ログイン・ページで入力されたIDの検証を行うコードを実装しておけば、認証されたユーザーだけにアプリケーションへのアクセスを許可できるようになる。この処理にしても、ヘルパ・メソッド（ユーティリティ的なメソッド）を利用すれば、以下のようにweb.configに登録されたユーザー名とパスワードのペアを参照して、ログイン・ページに入力されたIDと比較検証できるので、決まりきったコードを数行記述するだけで済む。
<credentials passwordFromat="Clear">
<user name="user1" password="himitsu" />
</credentials>
ただ、web.configにユーザー・アカウントを登録しておくのはセキュリティ上好ましいことではない。web.configはWebアプリケーションを配置しているフォルダに格納されていなければならないからだ。デフォルト設定のままでもweb.configがクライアントに送信されることはないが、web.configを編集したときに、うっかり「web.config~」などの名前でバックアップ・ファイルが作成されてしまった、などというミスが起こらないとは限らない。実際にはより安全な場所に独立したパスワード・ファイルを作成するか、ユーザー名とパスワードをデータベースに保存し、独自の検証コードを実装する必要があるだろう。
Copyright© Digital Advantage Corp. All Rights Reserved.