Tweet

連載 プログラミングASP.NET ―　ASP.NETによるWebアプリケーション実践開発講座　― 第17回　ASP.NETにおける認証と認定 田口 景介 2003/05/17
Page1 Page2 Page3

認証プロセス	内容
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）、わずか数行のコードを記述するだけでもフォーム認証を利用可能だ。

図17.4　フォーム認証で必要となるログイン・ページの例

フォーム認証では認証プロセスがアプリケーション・コードとして実装されるため、認証はWebページ上のフォームから行われる。

　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~」などの名前でバックアップ・ファイルが作成されてしまった、などというミスが起こらないとは限らない。実際にはより安全な場所に独立したパスワード・ファイルを作成するか、ユーザー名とパスワードをデータベースに保存し、独自の検証コードを実装する必要があるだろう。

INDEX
	プログラミングASP.NET
	第17回　ASP.NETにおける認証と認定
	1．認証（Authentication） - Windows認証とフォーム認証
	2．認定（Authorization） - ファイル認定とURL認定
	3．偽装（Impersonation）

「連載 ：プログラミングASP.NET」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード