ASP.NET セキュリティのデータ フロー
更新 : 2007 年 11 月
ASP.NET アプリケーションのセキュリティを設計する方法は多数あります。ここでは、2 つの一般的なシナリオを例として、セキュリティ データのフローについて説明します。第 1 のシナリオでは偽装を取り上げ、第 2 のシナリオでは Cookie を使用したフォーム認証を取り上げます。
シナリオ 1 : 偽装
偽装のシナリオでは、IIS (Microsoft Internet Information Services) による認証と Microsoft Windows のファイル アクセス セキュリティを利用することで、ASP.NET アプリケーション自体のセキュリティ プログラミングを最小限にしています。データ フローを次の図に示します。
偽装
.gif "ASP.NET ユーザー偽装データ フロー")
この図では、各イベントが次の順序で発生しています。
ネットワーク クライアントから IIS に要求が着信します。
IIS では、基本認証、ダイジェスト認証、または Windows 統合セキュリティ (NTLM または Kerberos) を使用してクライアントを認証します。
クライアントが認証されると、IIS は認証された要求を ASP.NET に渡します。
ASP.NET アプリケーションは、IIS から渡されたアクセス トークンを使用して要求の送信元クライアントを偽装し、NTFS ファイル アクセス許可を利用してリソースへのアクセス権を付与します。ASP.NET アプリケーションが必要とするのは、ASP.NET 構成ファイルで偽装が true に設定されていることを検証することだけで、ASP.NET セキュリティ コードは不要です。
偽装が有効になっていない場合、アプリケーションは ASP.NET プロセスの ID を使用して実行されます。Microsoft Windows 2000 Server と Windows XP Professional の場合、既定の ID は ASPNET という名前のローカル アカウントです。このアカウントは、ASP.NET のインストール時に自動的に作成されます。Microsoft Windows Server 2003 の場合、既定の ID は IIS アプリケーションのアプリケーション プールの ID (既定では NETWORK SERVICE アカウント) です。
.gif "メモ")
メモ :偽装が有効になっていない場合に、フォーム認証を使用して認証されたユーザーなどの特定のユーザーやユーザー グループのアクセスを制限するには、URL 承認などの別の承認方法を使用する必要があります。URL 承認の詳細については、「ASP.NET の承認」を参照してください。
ASP.NET アプリケーションで偽装を使用する方法の詳細については、「ASP.NET の偽装」および「ASP.NET の偽装と IIS 認証の使用」を参照してください。
アクセスが許可されると、ASP.NET アプリケーションは要求されたリソースを IIS 経由で返します。
シナリオ 2 : フォーム認証
フォーム認証のシナリオでは、アプリケーションはユーザー名やパスワードなどの資格情報をユーザーから直接収集し、資格情報の信頼性を独自に判断します。アプリケーションでは IIS 認証を使用しませんが、IIS 認証の設定はフォーム認証に影響します。一般に、フォーム認証を使用するときは IIS の匿名アクセスを有効にします。匿名アクセスが有効でないと、IIS 認証を渡さないユーザーは、ユーザー名とパスワードをフォーム認証に指定するためのアプリケーションにアクセスできません。
このシナリオにおけるデータ フローを次の図に示します。
フォーム認証
.gif "Cookie フロー")
この図では、各イベントが次の順序で発生しています。
保護されているリソースに対する要求がユーザーによって生成されます。
IIS が要求を受け取ります。IIS の匿名アクセスが有効になっているため、IIS はユーザー認証を実行せずに要求を ASP.NET アプリケーションに渡します。
ASP.NET の認証モードがフォームに設定されているため、ASP.NET アプリケーションはフォーム認証チケット (特定の Cookie) について要求を検証します。要求に認証チケットが添付されていない場合、ASP.NET は、アプリケーションの構成ファイルで指定されているログオン ページに要求をリダイレクトします。
このログオン ページで、ユーザーは必要な資格情報 (通常は名前とパスワード) を入力します。アプリケーション コードが資格情報を検証し、その信頼性を確認します。資格情報が認証されると、アプリケーション コードは、ユーザー資格情報を表す応答に認証チケットを添付します (パスワードは含まれません)。認証が失敗すると、応答はアクセスが拒否されたことを示すメッセージと共に返されるか、ログオン フォームが再表示されます。
発行される認証チケットは、ASP.NET アプリケーションへの後続の要求に含まれます。ASP.NET はメッセージ認証チェック (MAC: Message Authentication Check) を使用して、チケットの有効性を確認します。
ユーザーが認証されると、ASP.NET は承認を確認し、最初に要求されたリソースへのアクセスを許可するか、要求を別のページにリダイレクトするか、または要求をカスタム承認モジュールへリダイレクトします。カスタム承認モジュールでは、保護されたリソースへのアクセスを承認するかどうかについて、資格情報がテストされます。承認に失敗した場合、ASP.NET はユーザーをログオン ページにリダイレクトします。
ユーザーが承認されると、保護されているリソースへのアクセス権が与えられます。アプリケーションのデザインによっては、保護されているリソースへのアクセスを許可する前に、アプリケーションが資格情報に対する追加テストを要求する場合もあります。
メモ :フォーム認証および承認の確認は、authentication および authorization の各構成要素で保護されたリソースにのみ適用されます。アクセス制御リスト (ACL: Access Control List) を使用して保護されている Windows リソースへのアクセスは、ASP.NET アプリケーションの現在の Windows ID に対して検証されます。詳細については、「ASP.NET の偽装」を参照してください。