高速開発者が、多くの異なる人々がアクセスする銀行アプリケーションの構築を任されたとします。各人は自分のアカウント情報にアクセスしたいと思うでしょうが、他の人にはアクセスさせたくないでしょう。情報を所有するユーザー（または管理者）のみがアクセスできるように、MVCアプリケーションでアクセスを制限するためのベストプラクティスを知りたいです。
このAuthorize属性を使用すると、役割ごとに制限できます。これは出発点ですが、認証されたユーザーは他のユーザーの情報にアクセスできるようです。
ActionFiltersは、もう少しきめ細かい制御のオプションを提供しているようで、おそらくタスクを実行するために使用できます。ただし、それらが推奨されるアプローチであるかどうかはわかりません。
どんなガイダンスやアイデアでも大歓迎です。
ActionFilter はおそらく良い出発点ですが、アーキテクチャによっては、境界防御が十分かどうかを検討する必要がある場合があります。
基本的に単一層の ASP.NET MVC アプリケーションを構築している場合 (そして、これを行う完全に合理的な理由がある場合もあります)、ActionFilter は十分に優れた防御を提供すると同時に、非常に簡単に適用できます。
一方、アプリケーションが多層アプリケーションの場合は、多層防御がより適切です。その場合、承認ロジックをドメイン モデルまたはデータ アクセス レイヤーに適用することを検討する必要があります。これにより、同じドメイン モデル (Web サービスなど) に基づいて別のアプリケーションを開発した場合でも、承認ロジックが引き続き適用されることが保証されます。
何をするにしても、実際の承認の実装は IPrincipal に基づいていることを強くお勧めします。
より具体的には、ここで質問していることは、ACL ベースの承認でモデル化するのが最適です。各ユーザー プロファイルに ACL を設定し、デフォルトでは、ユーザー自身と管理者のみにアクセスを許可します。後で他のユーザーのプロファイルへの委任アクセスを許可するためにアプリケーションを拡張する必要がある場合 (特定のケースではリモートで現実的であるかどうかはわかりません)、ACL に新しいエントリを追加するだけでそれを行うことができます。
このような場合、アクセスの評価には、要求されたリソースの ACL を取得し、現在のユーザー (IPrincipal) がその ACL に含まれているかどうかを確認することが含まれます。このような操作は、プロセス外の操作 (データベースで ACL を検索する) を伴う可能性が非常に高いため、ActionFilter の背後に隠してアプリケーションの暗黙的な部分にすることは、パフォーマンスの問題を潜在的に隠す可能性があるように思えます。そのような場合、認可モデルをもう少し明示的/可視的にすることを検討します。
私の見解によると、単一層アプリケーションを使用している場合は、承認が最適なオプションであり、actionfilter の方がはるかに優れており、使いやすいです。ただし、アプリケーションが多層の場合は、アクセス制御リスト [ACL] を使用する必要があります。
おおよそ正しいと思いますが、ActionFilter アプローチは健全なものです。
AuthorizeAttribute から継承した一連のカスタム アクション フィルターを作成します。
Authorize 属性の機能に加えて、より厳格な所有者のみのポリシーを明確に実装できます。
HTH、
ダン