認証

October 2003

日本語版最終更新日 2005 年 1 月 13 日

適用対象:

    Microsoft® ASP.NET

    Microsoft Internet Information Services (IIS)

    Microsoft Visual Studio® .NET

    Microsoft Passport

    Java Server Pages (JSP)

概要 : ASP.NET アプリケーションで利用可能な認証方式とその実装方法について説明します。 JSP で使用されている認証方式についても簡単に紹介します。

目次

はじめに はじめに
JSP の認証 JSP の認証
CodeNotes の認証 CodeNotes の認証
JLCA による変換 JLCA による変換
ASP.NET の認証 ASP.NET の認証
まとめ まとめ

はじめに

認証とは、ユーザーが名乗っている本人であるかどうかを証明するプロセスです。 Web アプリケーションでは、認証は次の 2 つの部分から構成されるのが一般的です。 つまり、資格情報の問い合わせ (通常は何らかのインターフェイスを使用して、ログイン名とパスワードを要求) を行う部分と、その資格情報を何らかの情報ソース (データベースなど) に確認する部分です。 サーブレットと JSP によって開発されたアプリケーションのほとんどに、アクセスするユーザーを識別する何らかの認証プロセスが用意されています。 認証と "認可" が異なるプロセスであることを覚えておいてください。認可とは、Web サイトまたは Web アプリケーションのどの部分にユーザーがアクセスできるかを判断するプロセスで、認証が済んだ後に実行されます。

この記事では、まず、JSP でよく使用される認証方式について簡単に説明します。 認証は Web.xml (Java) ファイルや Web.config (Microsoft® ASP.NET) ファイルに結び付いているため、残念ながら、認証ルールを直接 Java Language Conversion Assistant (JLCA) で変換することはできません。 そこで、JLCA によって行われる処理を簡単に紹介し、変換プロセスを完了するにはどうすればよいのかを説明します。 最後に、ASP.NET アプリケーションで利用できるさまざまなタイプの認証方式を紹介し、新しい ASP.NET アプリケーションの認証プロセスを元の JSP アプリケーションの認証プロセスにできる限り近付けるにはこれらの認証方式をどのように実装すればよいのかを説明します。

JSP の認証

サーブレットと JSP には、次の 4 種類の認証方式があります。

  • 基本認証: HTTP/1.1 の仕様書で定義されている認証方式です。 ユーザーが JSP ページにアクセスしようとすると、システムからユーザー名とパスワードが要求されます (Web ブラウザに依存した組み込みインターフェイスが使用されます) 。ユーザー名とパスワードは数回 (通常は 3 回) 訂正することが可能となっており、その回数を超えるとエラー ページ (通常は、"HTTP 401 権限がありません" エラー) が表示されます。

  • フォーム認証: 基本認証に似た認証方式ですが、HTML を使用して独自のログイン インターフェイスを作成できるという点で異なっています。 この方式は基本認証よりも頻繁に使用されます。その理由は、ユーザー名とパスワード以外の項目 (電子メール アドレスや電話番号など) を使用した (追加した) ログイン インターフェイスを作成できるからです。

  • ダイジェスト認証: この方式も基本認証に似ていますが、パスワードをハッシュ式で暗号化するという点で異なっています。 パスワードのハッシュ値のみを HTTP に送信するため、基本認証よりも安全に認証を行うことができます。 しかし、ダイジェスト認証が使用されることはほとんどありません。セキュリティ確保のためのより安全で複雑な方法があるからです (HTTPS や SSL の使用など)。

  • クライアント証明書認証: この方式では、リソースにアクセスする各クライアントが認証のための証明書を送信します。 SSL (Secure Sockets Layer) プロトコルを使用して認証を行う必要があります。

JSP アプリケーションでは、一般に基本認証とフォーム認証のみが使用されます。 それぞれについて以下で説明します。

基本認証

JSP アプリケーションを保護する場合、基本認証を作成することができます。基本認証を使用すると、アプリケーション内のページにユーザーが新規セッションでアクセスするたびに、ユーザーのブラウザにダイアログが表示され、ユーザー名とパスワードの入力を求められるようになります。

ログイン構成

基本認証の使用をサーバーに指示するには、Web.xml ファイルに <login-config> 要素を追加する必要があります (ファイルにこの要素がまだ存在しない場合)。 通常、Web.xml はサーバーの WEB-INF ディレクトリに格納されています。 <login-config> 要素の記述例をリスト 1 に示します。

リスト 1. 基本認証用の <login-config> 要素
<login-config>
 <auth-method>BASIC</auth-method>
 <realm-name>CodeNotes Examples</realm-name> 
 </login-config> 

領域名 (realm-name) はアプリケーションにふさわしい名前に変更できます。 また、BASIC キーワードを使用して、認証方式を基本認証に指定している点に注意してください。 他の 3 つの認証方式を使用する場合も同様に、FORM、DIGEST、CLIENT-CERT と大文字のキーワードを指定します。

セキュリティ制約

次に、認証を行う各ページごとにセキュリティ制約を Web.xml に追加する必要があります。 <security-constraint> 要素の例をリスト 2 に示します。

リスト 2. 基本認証用の <security-constraint> 要素
<security-constraint> 
<web-resource-collection>
 <web-resource-name>Hello with BASIC protection</web-resource-name>
 <url-pattern>/HelloBasic.jsp</url-pattern> 
 </web-resource-collection> 
 <auth-constraint> 
 <role-name>codenotes</role-name> 
 </auth-constraint> 
 </security-constraint> 

ご覧のように、セキュリティ制約は 2 つの部分から構成されます。 1 つは Web リソース コレクションで、リソースの名前と URL を指定し、サーバーにこのページで認証を行うように指示します。もう 1 つは承認制約で、ページ アクセスを許可するロール (ユーザー グループ) を指定します。

ユーザー名とパスワード

ユーザー名およびパスワードの格納場所と格納方法は、サーブレットと JSP ページへのアクセスを提供するサーブレット コンテナごとに異なります。 たとえば、Tomcat サーブレットでは、Tomcat conf フォルダにある Tomcat-users.xml という名前の XML ファイルにクリア テキストで格納されます。 ユーザーごとに別々の <user> 要素に格納されます。リスト 3 に例を示します。

リスト 3. Tomcat-users.xml の <user> 要素
<user name=craig password=secret roles=codenotes /> 

各ユーザは、ユーザー名、パスワード、およびロール リストを持ちます。ロールとは、ユーザーが属するグループのことです。 roles 属性では、複数のロールをカンマで区切って指定することによって、ユーザーに複数のロールを与えることができます。 JSP ページへのアクセス権を、特定のユーザーではなく、"roles" に与えていることを覚えておいてください。

他のサーブレット コンテナや Web サーバーには、それぞれ独自のユーザー名とパスワードの格納方法が用意されています。 過去に JSP アプリケーションを開発した経験があれば、使用しているサーバーの格納方法についてはよく理解していると思いますが、わからない場合は、サーバーのドキュメントで確認してください。

ページ アクセス

上記の手順をすべて終了し、Microsoft® Internet Explorer で HelloBasic.jsp ページを開くと、ダイアログ ボックスが表示されます。 ページにアクセスするには、正しいユーザー名とパスワードを入力する必要があります。

<login-config> 要素に指定した領域名が、ダイアログ ボックスのサブタイトルとして使用されていることに注意してください。 また、Internet Explorer 以外のブラウザを使用している場合、ダイアログ ボックスの外観が異なるということも覚えておいてください。ただし、ダイアログ ボックスの基本的な構造と機能は変わりません。

フォーム認証

フォーム認証作成の基本的な手順は基本認証の場合とよく似ていますが、フォームを含むログイン ページを別途作成することにより、独自の認証を構成できるという点で異なっています。

ログイン構成

基本認証の場合と同様に、<login-config> 要素を Web.xml に追加します。ただし、要素の記述は若干複雑になります。その理由は、ログイン ページとログインに失敗した場合に表示するエラー ページの配置場所をサーバーに指示する必要があるからです。ただし、エラー ページの指定はオプションです。

フォーム認証を使用した JSP アプリケーションの <login-config> 要素の例をリスト 4 に示します。

リスト 4. フォーム認証用の <login-config> 要素
<login-config>
 <auth-method>FORM</auth-method>
 <form-login-config>
 <form-login-page>/login.jsp</form-login-page> 
 <form-error-page>/error.jsp</form-error-page> 
 </form-login-config> 
 </login-config> 

<realm-name> 要素が <form-login-config> 要素に置き換えられていることに注意してください。この要素にはログイン ページとエラー ページを指定します。 また、BASIC キーワードが FORM に置き換えられていることにも注意してください。

セキュリティ制約

<security-constraint> 要素については、基本認証の場合とまったく同じです。 フォーム認証を行うにあたって、特に追加することは何もありません。 ただし、このセクションの最後で提示する例については、認証を行うページの名前が HelloBasic.jsp ではなく、HelloForm.jsp になっているという点だけが異なっています。

ログイン フォームの作成

ログイン フォームでは、<form> 要素と <input> 要素のアクションと要素名に、特別なキーワードを指定して認証に使用します。 キーワードを指定することによって、この入力項目を格納されているユーザー情報と照合するようにサーバーに指示しています。 簡単なログイン ページの例をリスト 5 に示します。

リスト 5. 簡単なログイン ページ (login.jsp)
<html> 
<head><title>Login</title></head>
 <body> 
 <form action="j_security_check" method="post"> 
 <p>Enter your user name and password here.</p> 
 <p>User name: <input type="text" name="j_username" /></p> 
 <p>Password: <input type="password" name="j_password" />
 </p> 
 <p><input type="submit" value="Login" />
 </p> 
 </form> 
 </body> 
 </html> 

このページの目的は、ユーザー名とパスワードの入力フィールド、およびフィールド データ送信用の送信ボタンを用意することです。 ただし、フォームのアクションに j_security_check が指定されていること、およびユーザー名とパスワードの <input> 要素名が、それぞれ j_usernamej_password になっていることに注意してください。 これらのキーワードはサーブレット仕様書に定義されており、このフォームをログイン ページとして処理するために使用します。

エラー ページの作成

フォーム認証では、カスタム エラー ページを作成することができます。 リスト 6 に示す簡単なエラー ページの例では、ユーザーに資格情報が間違っていることを知らせています。また、ログイン ページに戻るためのボタンが用意されており、ユーザーがログインを再試行できるようになっています。

リスト 6. 簡単なエラー ページ (error.jsp)
<html>
 <head><title>Error</title></head> 
 <body> 
 <p>Sorry, you can't come in.</p>
 <form action='<%=response.encodeURL("login.jsp")%>' method="post"> 
 <input type="submit" value="Try Again" /> 
 </form> 
 </body> 
 </html> 

encodeURL() メソッドが使用されていることに注意してください。 このメソッドは、セッション ID が存在する場合は、指定された URL にセッション ID を付加してエンコードします。セッション ID が存在しない場合は、URL のみを返します。 request メソッドと response メソッドの詳細については、J2EE API のドキュメントを参照してください。

ページ アクセス

上記の手順をすべて終えて、Internet Explorer で HelloForm.jsp を開くと、ログイン ページが表示されます。 ユーザー名とパスワードが正しい場合は HelloForm.jsp が、間違っている場合は error.jsp が表示されます。

CodeNotes の認証

CodeNotes  leave-ms.gif Web サイトでは、フォーラムに記事を投稿する場合にのみ認証が行われます。 JSP バージョンの CodeNotes Web サイトでは、フォーム認証が使用されていますが、J2EE の仕様書で定義されている認証方式とは一致していません。 こうした状況は望ましいものとは言えませんが、サイトの特定のニーズには適合しています。 より一般的な方式は、Web サイトで行われるすべてのアクションに対してログインを義務付けることです。 このシナリオを実行するには、上記いずれかの認証方式を採用するのが適切でしょう。

JLCA による変換

認証を定義している Web.xml ファイルを、JLCA で変換することはできません。そのため、JSP アプリケーションで使用していた認証方式を、ASP.NET に直接移行することはできません。 幸いにも、認証方式の再実装は非常に簡単で、一部の構成を変更するだけで済みます。 JSP と ASP.NET の認証方式の関係を単純化すると、次のようになります。

1. JSP ASP.NET の認証マッピング

JSP

ASP.NET

変換方法

基本認証

基本認証/Microsoft Windows® 認証

ASP.NET の構成ファイルを変更

フォーム認証

フォーム認証

JLCA を使用してフォームを変換

ASP.NET の構成ファイルを変更

データベース アクセスの変更

エラー ページへのリンクを更新

ダイジェスト認証

N/A

別の方式を使用

クライアント証明書認証

N/A

フォーム認証に変換して再使用

 

Microsoft Passport 認証

変換の必要なし

以降で説明するように、ASP.NET の基本認証とフォーム認証のスタイルは、対応する JSP の認証方式によく似ています。

ASP.NET の認証

これまでのセクションを読めば、JSP で利用可能な認証オプションについて十分に理解できるはずです。 これまでの開発経験の中で、JSP の認証方式を使用したことがある、または少なくとも目にしたことがあるという人は多数いると思います。 これまでに説明した認証オプションを念頭に置き、これから ASP.NET の認証手順について解説します。具体的には、ASP.NET で利用可能な認証オプション、ASP.NET の認証と JSP の認証の類似点と相違点、および ASP.NET のさまざまな認証方法について説明します。

ここでは、次の 4 つの認証方式について説明します。それぞれ長所と短所があります。

  • Windows 認証: IIS によって制御および実行されます。主にイントラネットの Web アプリケーションで使用されます。

  • 基本認証: IIS によって制御および実行されます。安全なプロトコルではありませんが、セキュリティを必要としない場合、または SSL などセキュリティ面での対策が別途行われる場合に、インターネット アプリケーションで使用されます。

  • フォーム認証: 「JSP の認証」で解説したフォーム認証によく似た認証方式です。 ASP.NET の認証ページをより簡単に理解できるように、この類似点を取り上げて説明していきます。

  • Passport 認証: Microsoft Passport Web サービスを利用して認証を行います。

Windows 認証

統合 Windows 認証とも呼ばれる Windows 認証では、Windows オペレーティング システムのアカウントを利用してユーザーの資格情報を確認します。 この場合、ユーザーはサーバーが稼動するドメインに既にログイン済みか (この場合、資格情報は求められません)、または保護されたページにアクセスする際に、ログインを行う必要があります。 この方式は、IIS の機能の一部として制御および実行されます。ASP.NET とは完全に切り離されているため、それ自体は ASP.NET の認証メカニズムではありません。

Windows オペレーティング システムの種類によって、資格情報の正否を判別する機構が異なります。 Microsoft Windows NT® 4.0 の場合、ユーザー名とパスワード情報は SAM (Security Accounts Manager) に格納され、資格情報の確認は NTLM (NT LAN Manager) によって行われます。ただし、IIS 5.0 が ASP.NET の動作要件であること、また IIS 5.0 が動作するには Windows 2000 以降の環境が必要なことから、こうした機構を目にする機会はまずないでしょう。 Windows 2000 または Windows XP の場合、ユーザー名とパスワード情報は Microsoft Active Directory® データベースに格納され、資格情報の確認は Kerberos と呼ばれるプロトコルによって行われます。 オペレーティング システムの種類にかかわらず、資格情報の確認は暗黙的に行われます。また、認証の構成は、IIS ダイアログ ウィンドウの値をいくつか調整するだけで行うことができます。

Windows 認証を構成するには、インターネット サービス マネージャ (IIS の構成クライアント) を使用します。 Windows 2000 の場合、このプログラムを起動するには、[スタート] メニューから [プログラム]、[管理ツール] の順にポイントし、[インターネット サービス マネージャ] をクリックします。 Windows XP の場合は、[コントロール パネル] を開き、[管理ツール] 、[インターネット インフォメーション サービス] の順に選択します。

認証を構成するアプリケーションの仮想ディレクトリを探します。 ディレクトリ名を右クリックして、[プロパティ] をクリックし、[ディレクトリ セキュリティ] タブをクリックします。 [匿名アクセスと認証制御] の [編集] ボタンをクリックします。 表示される [認証方法] ウィンドウで IIS 認証ルールを構成します。

Windows 認証を有効にするには、[匿名アクセス] チェックボックスをオフにします。 この操作により、IIS は、この Web サイトでは匿名アクセスが許可されず、したがって資格情報が必要となることを認識します。

認証設定を変更したページをブラウザで開こうとすると、ユーザー名とパスワードの入力なしにページにアクセスできる場合があります。 これは、アプリケーションと同じドメインにログイン済みで、認証が既に完了しているためです。 ドメインにまだログインしていないユーザーは、アクセス時にログインする必要があります。ログインは 3 回まで試行できますが、すべて失敗した場合は IIS によってエラー ページが表示され、アクセスが拒否されます。

この認証方式で注意が必要なのは、サーバーが稼動するドメインにユーザーがログオン可能でなければならないことです。 つまり、統合 Windows 認証は、イントラネットの Web アプリケーションに対してのみ有効ということになります。リモートのユーザーがログオンできないからです。 ただし、パスワードをネットワーク上に送信しないため、このプロトコルは非常に安全です。したがって、イントラネットで Web アプリケーションを実行している場合は、安全性に劣る ASP.NET の基本認証やフォーム認証などよりも、この認証方式を採用するほうが望ましいと言えます。

基本認証

ASP.NET の基本認証は、JSP の基本認証とよく似ています。 基本認証が必要な Web リソースにアクセスすると、ブラウザ固有のログイン ダイアログが表示され、ユーザー名とパスワードの入力が求められます。 基本認証では、Windows 認証とは異なり、サーバーが属するドメインのアカウントをユーザーが保有する必要はありません。 ただし、JSP の基本認証 (およびフォーム認証) と同様、パスワードは base64 でエンコードされて HTTP に送信されます。暗号化は行われません。

構成

統合 Windows 認証と同様、基本認証は IIS によって実行されるため、構成も IIS で行う必要があります。 前セクションの説明に従って、[インターネット サービス マネージャ] から仮想ディレクトリ用の [認証方法] ダイアログを開きます。 匿名アクセスと統合 Windows 認証を無効にして、基本認証を有効にします。

アプリケーションに既定のドメイン名と領域名を指定していることに注意してください。 ドメイン名は、Web サービスのドメイン名 (つまり、アプリケーションにアクセス可能なドメイン名) に一致させる必要があります。 JSP の場合と同様、領域名は [ログイン] ダイアログ ボックスのサブタイトルに使用されます。 基本認証を選択すると、パスワードがネットワーク上にクリア テキストで送信され、大きなセキュリティ リスクを招くと IIS から警告されますので、その点にも注意してください。 前述のように、基本認証では安全性がまったく保障されていません。安全性を確保するには、SSL などのプロトコルを併用する必要があります。

ユーザー名とパスワード

基本認証を使用する場合、ユーザー名とパスワードは、サーバーが稼動しているシステム上にユーザー アカウントとして格納されます。 このため、ユーザー アカウントを追加するには、Windows のユーティリティを使用する必要があります。基本認証では、有効な Windows アカウントのみログインに使用できます。 [ユーザー アカウント] の設定ウィザードにはコントロール パネルからアクセスします。 システムへの新規ユーザーの作成は比較的簡単ですので、説明は省略します。

ASP.NET のセキュリティ構成

JSP の場合、ログインとセキュリティの構成は、Web.xml と呼ばれる XML ドキュメントで行ったことを思い出してください。同様に、すべての ASP.NET アプリケーションには Web.config という XML ファイルが用意されており、アプリケーション作成時に自動的に生成されます。 Web.config は、メモ帳などの任意のテキスト エディタで編集できます。また、Microsoft Visual Studio® .NET で開くことも可能ですが、その場合は画面右側の [ソリューション エクスプローラ] で Web.config をダブルクリックします。

Web.config を開いて、次の要素が記述されている箇所までスクロール ダウンしてください。


<authentication mode=Windows /> 

ASP.NET の認証設定は、この要素の内側にすべて記述します。 ただし、基本認証については、Web.config の設定を変更する必要はありません。後ほどフォーム認証について説明しますが、そのときにこの構成ファイルにさまざまな変更を行います。 ここでは、mode 属性に Windows を指定することで、アプリケーションの認証プロセスを IIS に処理させていることに注意してください。基本認証と統合 Windows 認証を使用する場合は、mode を Windows に指定します。

ページ アクセス

上記の手順に従って IIS を設定すると、アプリケーションを Web ブラウザで開いたときに、ログイン ダイアログが表示されるようになります。

このダイアログが、JSP の基本認証の例で表示されたダイアログとまったく同じであることに注意してください。 これは、ダイアログ ボックスのスタイルが、ブラウザの種類 (この場合は Internet Explorer) に依存するからです。アプリケーションやアプリケーションが稼動するサーバーの開発に使用されたプログラミング言語の違いは関係ありません。

Windows 基本認証の既定の動作では、ユーザー名とパスワードの訂正は 3 回まで可能になっています。 3 回とも失敗すると、"HTTP 401.2 権限がありません" というエラーが表示されます。 基本認証が ASP.NET ではなく IIS によって行われ、ASP.NET からリクエストの内容が参照できないため、カスタム エラー ページを作成することはできません。

フォーム認証

フォーム認証は基本認証に似ていますが、ログイン ページとエラー ページを独自に定義できるという点で異なっています。 さらに、基本認証の場合とは異なり、IIS の追加設定は必要ありません。 ここでの説明を始める前に、IIS の認証設定を元の状態に戻してください (匿名アクセスと統合 Windows 認証を有効にして、基本認証を無効にします)。

ログイン構成

「基本認証」では、Web.config というファイルについて紹介しました。 このファイルが Web アプリケーションごとに生成されること、およびこのファイルにアプリケーションの全構成情報が XML 形式で格納されることを思い出してください。 フォーム認証の使用をアプリケーションに指示するには、Web.config の <authentication> 要素を一部変更します。

Visual Studio .NET でアプリケーション プロジェクトを開きます。Web.config をダブルクリックして開き、<authentication> 要素の箇所までスクロール ダウンします。 リスト 7 のように修正します。

リスト 7. フォーム認証用の <authentication> 要素
<authentication mode="Forms"> 
<forms name="LoginForm" loginUrl="login.aspx" protection="All" />
 </authentication> 

name および loginUrl 属性については、特に説明の必要がないので省略します。 protection 要素については若干の説明が必要です。 フォーム認証を使用すると、ASP.NET は、Web アプリケーションにアクセスしているブラウザから Forms クッキーを探します。 クッキーが見つからない場合、指定されたログイン ページをブラウザに送信します。 クッキーを見つけた場合、ブラウザが現セッション中にログインを完了している (ユーザーが誰か既に認識している) と判断して、リクエストされたページを直接表示します。 protection 要素では、セキュリティ確保のための暗号化とデータ検証を、このクッキーに対してどの程度行うかを指定します。 All は最も安全で信頼性の高い設定値です。他の値も使用可能ですが、その詳細については MSDN® を参照してください。

IIS の認可機能で匿名ユーザーのアクセスを制御することはありません。そのため、Web.config に要素を 1 つ追加する必要があります。リスト 8 に示すように、<authorization> 要素を使用すると、特定のユーザーやユーザー グループに対して、アプリケーション使用の可否を指定できます。 リスト 8 の場合、匿名ユーザーのアクセスをすべて拒否しています (? は匿名ユーザーを表す特殊記号です)。

リスト 8. 匿名ユーザーのアクセスを拒否
<authorization> 
<deny users=? />
 </authorization> 

<deny> 要素に特定のユーザー名を指定して、あるユーザーのアクセスは拒否し、他のユーザーは許可するといった設定も可能です。

ユーザー名とパスワード

認証を行うにあたり、ユーザー名とパスワードの最も簡単な格納方法は、他の認証情報とともに Web.config XML ファイルに記述することです。 ただし、ASP.NET ではユーザー名とパスワードにプログラム的にアクセスできるため、データベースや独自に作成したカスタム XML ファイルからこの情報を簡単に取得できます。 多くの場合、こうした処理方法が好まれます (JSP アプリケーションでも同様の実装が行われているはずです)。すぐ後で ASP.NET のコードを見ていきますが、その際にこうしたコードの追加場所と追加するタイミングについて説明します。

ここでは、先ほどと同様に Web.config から <authentication> 要素を探して、リスト 9 に示すコードを追加します。

リスト 9. Web.config にユーザー名とパスワード情報を格納
<authentication mode="Forms">
 <forms name="LoginForm" loginUrl="login.aspx" protection="All" />
 <credentials passwordFormat="Clear">
 <user name="craig" password="secret"/> 
 </credentials> 
 </forms>
 </authentication> 

<credentials> 要素を使用して、アプリケーションの利用可能ユーザー リストに、ユーザーを 1 人追加しています。 リストのユーザーとの照合方法については、この後で説明します。 ここでは、passwordFormat 属性の値に Clear を指定すると、人が読むことのできる (エンコードされない) 形式でパスワードが格納されるということに注意してください。 別の値を指定すると、パスワードは暗号化されてネットワークに送信されます。

ログイン フォームの作成

ASP.NET の場合、JSP の例とは異なり、Visual Studio .NET のフォーム デザイナを使用して、ログイン フォームの外観をデザインできます。また、CodeBehind ファイルに重要なコードをすべて記述できます。 このため、Web の画面を具体的にイメージしながらフォームをデザインできます。また、C# のコードの大部分を、HTML のページ デザインから分離できます。

プロジェクトに Login.aspx という名前のフォームを新規に追加することから始めます。このフォームにいくつかのテキスト フィールドとボタンを 1 つ追加します。必要なコンポーネントをデザイン ウィンドウにドラッグ アンド ドロップして配置を整えるだけで、JSP の例で作成したフォームと同じような外観のフォームを作成できます。

Login.aspx の CodeBehind ファイルを開いて、2 か所にコードを追加します。 まず、ページの先頭に次の using ディレクティブを追加します。

using System.Web.Security; 

この名前空間には、ASP.NET のセキュリティ確保に必要なすべてのクラスが格納されています。

次に、[ログイン] ボタンの Click メソッドに、ユーザー名とパスワードを確認するためのコードを追加します。 CodeBehind に Button1_Click メソッドがまだ作成されていない場合は、フォーム エディタに戻り、[ログイン] ボタンをダブルクリックして追加してください。 Button1_Click メソッドの内側に、リスト 10 に示すコードを追加します。

リスト 10. フォーム認証用の Button1_Click コード
private void Button1_Click(object sender, System.EventArgs e) { 
if (FormsAuthentication.Authenticate(TextBox1.Text, TextBox2.Text)) {
 FormsAuthentication.RedirectFromLoginPage(TextBox1.Text, false); 
 } else {
 Label1.Text = "Login failed. Please try again.";
 }
 } 

ご覧のように、このコードには、System.Web.Security 名前空間に属する FormsAuthentication オブジェクトのメソッドが 2 つ使用されています。

Authenticate() は、ユーザー名とパスワードを表す文字列パラメータを 2 つ受け取り、Web.config のユーザー リストと照合します。この場合は、2 つのフィールドの値が格納されている資格情報と適合するかどうかを確認します。

RedirectFromLoginPage() メソッドも同様に 2 つのパラメータを受け取ります。 1 つはユーザー名で、アプリケーションの認可ポリシーに渡されます。 認可ポリシーは基本的に、アプリケーションでユーザーがアクセスできる部分とできない部分を判断するために使用されます。 もう 1 つのパラメータは、ユーザーに永続的なクッキーを送信するかどうかを示すブール値です。 この値を false に設定すると、ブラウザの新しいウィンドウでアプリケーションを開く場合に、ユーザーの再ログインが必要になります。true に設定すると、複数のウィンドウで継続的にページを使用できるようになり、ウィンドウを開くたびにログインする必要がなくなります。

認証から資格情報確認後までの流れが、完全にプログラム的になっていることに注意してください。 このため、FormsAuthentication クラスを使用して Web.config ファイルと照合する代わりに、入力された資格情報をユーザー データベースやカスタム XML ファイルと比較することも簡単にできます。 Web.config にユーザー名とパスワードを格納し、組み込みフォームの認証機能を利用するやり方は確かに簡単ですが、それが唯一最良の方法というわけではありません。

また、認証が失敗した場合に、同じページのメッセージを単純に変更するのではなく、カスタム エラー ページにユーザーをリダイレクトすることも簡単にできます。これは、この記事の前半で紹介した JSP の例と同じやり方です。

ページ アクセス

プロジェクトを保存してコンパイルすると、Web ブラウザでページにアクセスできるようになります。 たとえば、アプリケーション名が HelloForms の場合は、ブラウザに http://localhost/HelloForms/WebForm1.aspx と指定することで、ログイン ページをテストできます。 ブラウザがログイン ページにリダイレクトされます。

このページが、JSP のフォーム認証の例で使用したログイン ページとよく似ているこを確認してください。 間違った資格情報を入力すると、ウィンドウ上部のラベルがエラー メッセージに変わります。 正しい資格情報 (craig と secret など) を入力すると、WebForm1.aspx が表示されます。

Passport 認証

.NET では Passport 認証システムを使用することもできます。 これは、単一のログインで認証と認可を行う独立したシステムです。 つまり、Passport に一度サインインするだけで、Passport 認証を導入しているすべての Web サイトまたは Web アプリケーションにサインインできることになります。 Passport および ASP.NET アプリケーションでの Passport 利用の詳細については、MSDN ライブラリを参照してください。

まとめ

認証とは、ユーザー名やパスワードなどの資格情報を使用して、アクセスするユーザーを識別するプロセスのことです。 JSP と ASP.NET のどちらも、さまざまな方法で Web アプリケーションに認証手続きを実装することができます。 ASP.NET で Web アプリケーションを開発している場合、IIS または ASP.NET 自体によって認証が行われます。

IIS の認証オプションには、統合 Windows 認証と基本認証が用意されています。統合 Windows 認証では、組み込みのログイン アプリケーションが使用され、ユーザーはアプリケーションが稼動しているドメインにサインインする必要があります。基本認証でも、組み込みのログイン フォームが使用され、ユーザーはサーバーにアカウントを持つ必要があります。ただし、ネットワークに送信する際に、ユーザー名とパスワードの暗号化は行われません。

ASP.NET を使用すると、ログイン画面用にカスタマイズした Web フォームを作成して、資格情報の格納場所と確認方法をプログラム的に決定できます。また、成功した場合と失敗した場合のそれぞれについて、認証後の処理を指定できます。 このフォーム認証は JSP のフォーム認証によく似ており、Web アプリケーションではおそらく最も一般的な認証方法です。 Visual Studio .NET を使用すると、Web フォームを非常に間単に作成できます。フォームをデザインする際に、コードを記述する必要がまったくないからです。 ASP.NET では、Microsoft Passport 認証を使用することもできます。 これはフォーム認証に似ていますが、ログインと資格情報の確認が外部の Microsoft Passport Web サービスによって行われるという点で異なります。 運営するサイトで Passport 認証を使用するには、Microsoft Passport に登録する必要があります。その際には、登録料の支払いとともに、事業内容と Web アプリケーションに関する情報を提供する必要があります。

ASP.NET にはさまざまな認証オプションが用意されており、ニーズ、セキュリティ条件、および時間的な制約を考慮して、最適な認証方式を選択できます。

表示: