セキュリティの基礎と ASP.NET のサポート (VB)

  • [アーティクル]

作成者: Scott Mitchell

注意

この記事が作成されて以来、ASP.NET メンバーシップ プロバイダーは ASP.NET Identity に置き換えられました。 この記事の執筆時点で取り上げられたメンバーシップ プロバイダーではなく 、ASP.NET ID プラットフォームを使用するようにアプリを更新することを強くお勧めします。 ASP.NET ID には、ASP.NET メンバーシップ システムに比して、次のような多くの利点があります。

  • パフォーマンスの向上
  • 拡張性とテスト性の向上
  • OAuth、OpenID Connect、および 2 要素認証のサポート
  • クレームベースの ID のサポート
  • ASP.Net Core との相互運用性の向上

PDF のダウンロード

これは、Web フォームを介して訪問者を認証し、特定のページと機能へのアクセスを承認し、ASP.NET アプリケーションでユーザー アカウントを管理するための手法を調べる一連のチュートリアルの最初のチュートリアルです。

はじめに

フォーラム、e コマース サイト、オンライン メール Web サイト、ポータル Web サイト、ソーシャル ネットワーク サイトの共通点は何ですか? これらはすべて ユーザー アカウントを提供します。 ユーザー アカウントを提供するサイトでは、さまざまなサービスを提供する必要があります。 少なくとも、新しい訪問者はアカウントを作成でき、返却する訪問者はログインできる必要があります。 このような Web アプリケーションは、ログインしているユーザーに基づいて決定を下すことができます。一部のページまたはアクションは、ログインしているユーザーのみに制限されるか、特定のユーザーのサブセットに制限される場合があります。他のページには、ログインしているユーザーに固有の情報が表示される場合や、ページを表示しているユーザーに応じて多かれ少なかれ情報が表示される場合があります。

これは、Web フォームを介して訪問者を認証し、特定のページと機能へのアクセスを承認し、ASP.NET アプリケーションでユーザー アカウントを管理するための手法を調べる一連のチュートリアルの最初のチュートリアルです。 これらのチュートリアルでは、次の方法について説明します。

  • ユーザーを特定して Web サイトにログインする
  • ASP を使用します。ユーザー アカウントを管理するための NET のメンバーシップ フレームワーク
  • ユーザー アカウントの作成、更新、削除
  • ログインしているユーザーに基づいて、Web ページ、ディレクトリ、または特定の機能へのアクセスを制限する
  • ASP を使用します。ユーザー アカウントをロールに関連付ける NET のロール フレームワーク
  • ユーザー ロールの管理
  • ログインしているユーザーのロールに基づいて、Web ページ、ディレクトリ、または特定の機能へのアクセスを制限する
  • ASP をカスタマイズして拡張する。NET のセキュリティ Web コントロール

これらのチュートリアルは簡潔にし、プロセスを視覚的に説明するためのスクリーン ショットを豊富に備えた詳細な手順を提供します。 各チュートリアルは、C# と Visual Basic のバージョンで使用でき、使用される完全なコードのダウンロードが含まれています。 (この最初のチュートリアルでは、高レベルの観点からセキュリティの概念に焦点を当てているため、関連するコードは含まれていません)。

このチュートリアルでは、重要なセキュリティの概念と、フォーム認証、承認、ユーザー アカウント、ロールの実装に役立つ ASP.NET で利用できる機能について説明します。 それでは作業を始めましょう。

注意

セキュリティは、物理的、技術的、およびポリシーの決定に及び、高度な計画とドメインの知識を必要とするアプリケーションの重要な側面です。 このチュートリアル シリーズは、セキュリティで保護された Web アプリケーションを開発するためのガイドではありません。 むしろ、フォーム認証、承認、ユーザー アカウント、ロールに特に焦点を当てています。 これらの問題を中心に展開する一部のセキュリティ概念については、このシリーズで説明しますが、他の概念は未確認のままです。

認証、承認、ユーザー アカウント、ロール

認証、承認、ユーザー アカウント、ロールは、このチュートリアル シリーズ全体で非常に頻繁に使用される 4 つの用語であるため、Web セキュリティのコンテキスト内でこれらの用語を簡単に定義したいと思います。 インターネットなどのクライアント/サーバー モデルでは、要求を行うクライアントをサーバーが識別する必要があるシナリオが多数あります。 認証 は、クライアントの ID を確認するプロセスです。 正常に識別されたクライアントは 、認証されていると言われます。 未確認のクライアントは、 認証されていない か 匿名であると言われます。

セキュリティで保護された認証システムには、知 っているもの、持っているもの、または自分が持っているものの 3 つのファセットのうち少なくとも 1 つが含まれます。 ほとんどの Web アプリケーションは、パスワードや PIN など、クライアントが認識しているものに依存しています。 ユーザーを識別するために使用される情報 (ユーザー名とパスワードなど) は、 資格情報と呼ばれます。 このチュートリアル シリーズでは、 フォーム認証に焦点を当てています。これは、ユーザーが Web ページ フォームで資格情報を指定してサイトにログインする認証モデルです。 私たちは皆、この種の認証を経験しました。 任意の e コマース サイトに移動します。 チェックする準備ができたら、Web ページのテキスト ボックスにユーザー名とパスワードを入力してログインするように求められます。

サーバーでは、クライアントの識別に加えて、要求を行うクライアントに応じて、アクセス可能なリソースまたは機能を制限する必要がある場合があります。 承認 とは、特定のユーザーが特定のリソースまたは機能にアクセスする権限を持っているかどうかを判断するプロセスです。

ユーザー アカウントは、特定のユーザーに関する情報を保持するためのストアです。 ユーザー アカウントには、ユーザーのログイン名やパスワードなど、ユーザーを一意に識別する情報を最小限に抑える必要があります。 この重要な情報に加えて、ユーザー アカウントには、ユーザーのメール アドレスなどの情報が含まれる場合があります。アカウントが作成された日時。最後にログインした日時。名と姓。電話番号;および郵送先住所。 フォーム認証を使用する場合、ユーザー アカウント情報は通常、Microsoft SQL Server などのリレーショナル データベースに格納されます。

ユーザー アカウントをサポートする Web アプリケーションでは、必要に応じてユーザーを ロールにグループ化できます。 ロールは、単にユーザーに適用されるラベルであり、承認規則とページ レベルの機能を定義するための抽象化を提供します。 たとえば、Web サイトには、管理者以外のユーザーが特定の Web ページセットにアクセスすることを禁止する承認規則を持つ管理者ロールが含まれている場合があります。 さらに、すべてのユーザー (管理者以外を含む) がアクセスできるさまざまなページでは、管理者ロールのユーザーがアクセスしたときに、追加のデータが表示されたり、追加の機能が提供されたりすることがあります。 ロールを使用すると、ユーザー単位ではなくロールごとにこれらの承認規則を定義できます。

ASP.NET アプリケーションでのユーザーの認証

ユーザーがブラウザーのアドレス ウィンドウに URL を入力するか、リンクをクリックすると、ブラウザーは、指定されたコンテンツ (ASP.NET ページ、画像、JavaScript ファイル、またはその他の種類のコンテンツなど) に対して、Web サーバーに ハイパーテキスト転送プロトコル (HTTP) 要求を行います。 Web サーバーは、要求されたコンテンツを返すタスクを実行します。 その際、要求に関するさまざまなことを決定する必要があります。これには、要求を行ったユーザーや、要求されたコンテンツを取得する ID が承認されているかどうかなどが含まれます。

既定では、ブラウザーは識別情報がない HTTP 要求を送信します。 ただし、ブラウザーに認証情報が含まれている場合、Web サーバーは認証ワークフローを開始し、要求を行うクライアントを識別しようとします。 認証ワークフローの手順は、Web アプリケーションで使用される認証の種類によって異なります。 ASP.NET では、Windows、Passport、フォームの 3 種類の認証がサポートされています。 このチュートリアル シリーズでは、フォーム認証に焦点を当てていますが、ユーザー ストアとワークフロー Windows 認証比較して比較してみましょう。

Windows 認証を使用した認証

Windows 認証 ワークフローでは、次のいずれかの認証手法を使用します。

  • [基本認証]
  • ダイジェスト認証
  • Windows 統合認証

3 つの手法は、ほぼ同じように機能します。承認されていない匿名要求が到着すると、Web サーバーは承認が続行する必要があることを示す HTTP 応答を返します。 ブラウザーには、ユーザーにユーザー名とパスワードの入力を求めるモーダル ダイアログ ボックスが表示されます (図 1 を参照)。 その後、この情報は HTTP ヘッダーを介して Web サーバーに送り返されます。

ユーザーに資格情報の入力を求めるモーダル ダイアログ ボックス

図 1: モーダル ダイアログ ボックスでユーザーに資格情報の入力を求める

指定された資格情報は、Web サーバーの Windows ユーザー ストアに対して検証されます。 つまり、Web アプリケーションで認証された各ユーザーは、organizationに Windows アカウントを持っている必要があります。 これは、イントラネット シナリオでは一般的です。 実際、イントラネット設定で Windows 統合認証を使用する場合、ブラウザーはネットワークへのログオンに使用される資格情報を Web サーバーに自動的に提供するため、図 1 に示すダイアログ ボックスは表示されません。 Windows 認証はイントラネット アプリケーションに適していますが、サイトにサインアップするすべてのユーザーに対して Windows アカウントを作成する必要がないため、通常はインターネット アプリケーションでは実現できません。

フォーム認証による認証

一方、フォーム認証はインターネット Web アプリケーションに最適です。 フォーム認証では、Web フォームを使用して資格情報を入力するように求めることで、ユーザーを識別することを思い出してください。 そのため、ユーザーが承認されていないリソースにアクセスしようとすると、資格情報を入力できるログイン ページに自動的にリダイレクトされます。 送信された資格情報は、カスタム ユーザー ストア (通常はデータベース) に対して検証されます。

送信された資格情報を確認すると、ユーザーの フォーム認証チケット が作成されます。 このチケットは、ユーザーが認証され、ユーザー名などの識別情報が含まれていることを示します。 フォーム認証チケットは、(通常は) クライアント コンピューターに Cookie として格納されます。 そのため、Web サイトへの後続のアクセスには HTTP 要求にフォーム認証チケットが含まれているため、Web アプリケーションはログイン後にユーザーを識別できます。

図 2 は、高レベルの視点からのフォーム認証ワークフローを示しています。 ASP.NET の認証と承認の部分が 2 つの個別のエンティティとしてどのように機能するかに注目してください。 フォーム認証システムは、ユーザーを識別します (または、匿名であることを報告します)。 承認システムは、ユーザーが要求されたリソースにアクセスできるかどうかを決定します。 ユーザーが承認されていない場合 (図 2 のように、ProtectedPage.aspxに匿名でアクセスしようとするとき)、承認システムはユーザーが拒否されたことを報告し、フォーム認証システムによってユーザーがログイン ページに自動的にリダイレクトされます。

ユーザーが正常にログインすると、後続の HTTP 要求にはフォーム認証チケットが含まれます。 フォーム認証システムは、単にユーザーを識別するだけです。これは、ユーザーが要求されたリソースにアクセスできるかどうかを決定する承認システムです。

フォーム認証ワークフロー

図 2: フォーム認証ワークフロー

フォーム認証の詳細については、次のチュートリアル「フォーム認証の概要」を参照してください。 ASP の詳細については、以下を参照してください。NET の認証オプションについては、「 ASP.NET 認証」を参照してください。

Web ページ、ディレクトリ、およびページ機能へのアクセスを制限する

ASP.NET には、特定のユーザーが特定のファイルまたはディレクトリにアクセスする権限を持っているかどうかを判断する 2 つの方法が含まれています。

  • ファイルの承認 - ASP.NET ページと Web サービスは Web サーバーのファイル システム上に存在するファイルとして実装されるため、これらのファイルへのアクセスは、Access Control Lists (ACL) を介して指定できます。 ACL は Windows アカウントに適用されるアクセス許可であるため、ファイルの承認は Windows 認証 で最もよく使用されます。 フォーム認証を使用する場合、サイトにアクセスするユーザーに関係なく、すべてのオペレーティング システム レベルとファイル システム レベルの要求が同じ Windows アカウントによって実行されます。
  • URL 承認 - URL 承認を使用して、ページ開発者は Web.config で承認規則を指定します。これらの承認規則では、アプリケーション内の特定のページまたはディレクトリへのアクセスを許可または拒否されるユーザーまたはロールを指定します。

ファイル承認と URL 承認では、特定の ASP.NET ページにアクセスするための承認規則、または特定のディレクトリ内のすべての ASP.NET ページに対する承認規則を定義します。 これらの手法を使用して、特定のユーザーに対する特定のページへの要求を拒否するか、一連のユーザーへのアクセスを許可し、他のすべてのユーザーへのアクセスを拒否するように ASP.NET に指示できます。 すべてのユーザーがページにアクセスできるが、ページの機能はユーザーによって異なるシナリオはどうでしょうか。 たとえば、ユーザー アカウントをサポートする多くのサイトには、認証されたユーザーと匿名ユーザーの異なるコンテンツまたはデータを表示するページがあります。 匿名ユーザーにはサイトにログインするためのリンクが表示される場合があります。一方、認証されたユーザーには、ログアウトするためのリンクと共に、[ようこそ戻る ]、[ユーザー名] などのメッセージが表示されます。別の例: オークション サイトでアイテムを表示する場合は、入札者であるか、アイテムをオークションしているかによって異なる情報が表示されます。

このようなページ レベルの調整は、宣言的またはプログラムによって行うことができます。 匿名ユーザーとは異なるコンテンツを表示するには、 LoginView コントロール をページにドラッグし、適切なコンテンツを AnonymousTemplate テンプレートと LoggedInTemplate テンプレートに入力します。 または、現在の要求が認証されているかどうか、ユーザーが誰であるか、および属しているロール (存在する場合) をプログラムで判断することもできます。 この情報を使用して、グリッドまたはページ上のパネルの列の表示と非表示を切り替えることができます。

このシリーズには、承認に焦点を当てた 3 つのチュートリアルが含まれています。 ユーザー ベースの承認では、特定のユーザー アカウントのディレクトリ内のページへのアクセスを制限する方法を調べます。 ロールベースの承認 では、ロール レベルで承認規則を指定します。最後に、 現在ログインしているユーザーに基づいてコンテンツを表示するチュートリアルでは 、ページにアクセスするユーザーに基づいて特定のページのコンテンツと機能を変更する方法について説明します。 ASP の詳細については、以下を参照してください。NET の承認オプションについては、「 ASP.NET 承認」を参照してください。

ユーザー アカウントとロール

Asp。NET のフォーム認証は、ユーザーがサイトにログインし、その認証状態をページ 訪問間で記憶するためのインフラストラクチャを提供します。 URL 承認では、ASP.NET アプリケーション内の特定のファイルまたはフォルダーへのアクセスを制限するためのフレームワークが提供されます。 ただし、どちらの機能も、ユーザー アカウント情報を格納したり、ロールを管理したりするための手段を提供します。

ASP.NET 2.0 より前は、開発者は独自のユーザーとロール ストアを作成する責任がありました。 また、ユーザー インターフェイスを設計し、ログイン ページや新しいアカウントを作成するページなどの重要なユーザー アカウント関連ページのコードを記述するためのフックにもなっていました。 ASP.NET に組み込みのユーザー アカウント フレームワークがない場合、ユーザー アカウントを実装する各開発者は、パスワードやその他の機密情報を格納操作方法などの質問に関する独自の設計上の決定に到達する必要がありました。また、パスワードの長さと強度に関してどのようなガイドラインを適用する必要がありますか?

現在、 メンバーシップ フレームワーク と組み込みの Login Web コントロールにより、ASP.NET アプリケーションでのユーザー アカウントの実装がはるかに簡単になっています。 Membership フレームワークは、 System.Web.Security 名前空間 の少数のクラスで、重要なユーザー アカウント関連のタスクを実行するための機能を提供します。 Membership フレームワークのキー クラスは Membership クラスで、次のようなメソッドがあります。

  • CreateUser
  • DeleteUser
  • GetAllUsers
  • GetUser
  • UpdateUser
  • Validateuser

Membership フレームワークは プロバイダー モデルを使用します。これにより、Membership フレームワークの API とその実装がクリーンに分離されます。 これにより、開発者は共通の API を使用できますが、アプリケーションのカスタム ニーズを満たす実装を使用できるようになります。 つまり、Membership クラスはフレームワークの重要な機能 (メソッド、プロパティ、イベント) を定義しますが、実際には実装の詳細は提供しません。 代わりに、Membership クラスのメソッドは、構成されたプロバイダーを呼び出します。これは、実際の作業を実行します。 たとえば、Membership クラスの CreateUser メソッドが呼び出されると、Membership クラスはユーザー ストアの詳細を認識しません。 ユーザーがデータベース、XML ファイル、またはその他のストアで保守されているかどうかはわかりません。 Membership クラスは、Web アプリケーションの構成を調べて、呼び出しを委任するプロバイダーを決定します。そのプロバイダー クラスは、適切なユーザー ストアに新しいユーザー アカウントを実際に作成する役割を担います。 この相互作用を図 3 に示します。

Microsoft は、.NET Frameworkに 2 つのメンバーシップ プロバイダー クラスを提供しています。

  • ActiveDirectoryMembershipProvider - Active Directory および Active Directory アプリケーション モード (ADAM) サーバーにメンバーシップ API を実装します。
  • SqlMembershipProvider - SQL Server データベースにメンバーシップ API を実装します。

このチュートリアル シリーズでは、SqlMembershipProvider のみに焦点を当てています。

プロバイダー モデルを使用すると、さまざまな実装をフレームワークにシームレスに接続できます

図 03: プロバイダー モデルを使用すると、さまざまな実装をフレームワークにシームレスに接続できます (クリックするとフルサイズの画像が表示されます)

プロバイダー モデルの利点は、Microsoft、サードパーティベンダー、または個々の開発者が代替実装を開発し、メンバーシップ フレームワークにシームレスに接続できることです。 たとえば、Microsoft は Microsoft Access データベースのメンバーシップ プロバイダーをリリースしました。 メンバーシップ プロバイダーの詳細については、 Provider Toolkit を参照してください。これには、メンバーシップ プロバイダーのチュートリアル、サンプル カスタム プロバイダー、プロバイダー モデルに関する 100 ページを超えるドキュメント、組み込みのメンバーシップ プロバイダー (つまり、ActiveDirectoryMembershipProvider と SqlMembershipProvider) の完全なソース コードが含まれています。

ASP.NET 2.0 では、Roles フレームワークも導入されました。 メンバーシップ フレームワークと同様に、Roles フレームワークはプロバイダー モデルの上に構築されます。 その API は Roles クラスを介して公開され、.NET Frameworkには次の 3 つのプロバイダー クラスが付属しています。

  • AuthorizationStoreRoleProvider - Active Directory や ADAM などの承認マネージャー ポリシー ストアのロール情報を管理します。
  • SqlRoleProvider - SQL Server データベースにロールを実装します。
  • WindowsTokenRoleProvider - 訪問者の Windows グループに基づいてロール情報を関連付けます。 このメソッドは通常、Windows 認証と共に使用されます。

このチュートリアル シリーズでは、SqlRoleProvider のみに焦点を当てています。

プロバイダー モデルには単一の前方向き API (Membership クラスと Roles クラス) が含まれているので、実装の詳細を気にすることなく、その API に関する機能を構築できます。これらは、ページ開発者によって選択されたプロバイダーによって処理されます。 この統合 API を使用すると、Microsoft およびサード パーティベンダーは、Membership および Roles フレームワークとインターフェイスする Web コントロールを構築できます。 ASP.NET には、共通のユーザー アカウント ユーザー インターフェイスを実装するための 多数のログイン Web コントロール が付属しています。 たとえば、 Login コントロール は、ユーザーに資格情報の入力を求め、検証してから、フォーム認証を使用してログインします。 LoginView コントロールには、匿名ユーザーと認証済みユーザーに対して異なるマークアップを表示するためのテンプレート、またはユーザーのロールに基づいて異なるマークアップを表示するためのテンプレートが用意されています。 また、 CreateUserWizard コントロール には、新しいユーザー アカウントを作成するための詳細なユーザー インターフェイスが用意されています。

の下には、さまざまなログイン コントロールがメンバーシップおよびロール フレームワークと対話します。 ほとんどのログイン コントロールは、1 行のコードを記述しなくても実装できます。 今後のチュートリアルでは、これらのコントロールの機能を拡張およびカスタマイズするための手法など、これらのコントロールについて詳しく調べます。

まとめ

ユーザー アカウントをサポートするすべての Web アプリケーションには、次のような同様の機能が必要です。たとえば、ユーザーがログインし、ページアクセス全体でログイン状態を記憶する機能。新規訪問者がアカウントを作成するための Web ページ。およびページ開発者が、どのリソース、データ、および機能をどのユーザーまたはロールで使用できるかを指定する機能。 フォーム認証、URL 承認、メンバーシップとロール フレームワークにより、ユーザーの認証と承認、およびユーザー アカウントとロールの管理のタスクは、ASP.NET アプリケーションで非常に簡単に実行できます。

次のいくつかのチュートリアルでは、作業用 Web アプリケーションを一から段階的に構築することで、これらの側面について説明します。 次の 2 つのチュートリアルでは、フォーム認証について詳しく説明します。 フォーム認証ワークフローの動作を確認し、フォーム認証チケットを解剖し、セキュリティ上の懸念事項について説明し、フォーム認証システムを構成する方法を確認します。また、訪問者がログインおよびログアウトできる Web アプリケーションを構築する際に確認します。

幸せなプログラミング!

もっと読む

このチュートリアルで説明するトピックの詳細については、次のリソースを参照してください。

著者について

7 冊の ASP/ASP.NET 書籍の著者であり、 4GuysFromRolla.com の創設者である Scott Mitchell は、1998 年から Microsoft Web テクノロジと協力しています。 Scott は独立したコンサルタント、トレーナー、ライターとして働いています。 彼の最新の本は サムズ・ティーチ・自分自身 ASP.NET 24時間で2.0です。 にアクセスmitchell@4GuysFromRolla.comすることも、ブログを介して アクセスすることもできます。これは でhttp://ScottOnWriting.NET確認できます。

特別な感謝

このチュートリアル シリーズは、多くの役立つ校閲者によってレビューされました。 このチュートリアルのリード レビュー担当者は、このチュートリアル シリーズは多くの役立つレビュー担当者によってレビューされました。 このチュートリアルのリード レビュー担当者には、Alicja Maziarz、John Suru、Toria Murphy が含まれます。 今後の MSDN 記事の確認に関心がありますか? その場合は、 に行mitchell@4GuysFromRolla.comをドロップしてください。

次へ