1

MSDN は、MVC ルーティングとセキュリティについて非常に明確です。

MVC アプリケーションを保護するためにサポートされている唯一の方法は、各コントローラーに AuthorizeAttribute 属性を適用し、login および register アクションで AllowAnonymousAttribute 属性を使用することです。

ただし、次のアプローチを検討しています。

まず、カスタム STS からの情報に基づいてセキュリティ チェックを実行するカスタム コントローラー ファクトリを実装しました。

とりわけ、STS によって発行されるトークンには、ユーザーがアクセスできるすべての MVC ルートを記述するクレームが含まれています。

次に、CreateController メソッド内のユーザー クレームを確認します。

public class SecuredControllerFactory : IControllerFactory
{
   public IController CreateController(System.Web.Routing.RequestContext requestContext, string controllerName)
    {
        ...
        bool isAuthorized = principal.HasRequiredRight(verb, ressource);
        ...
    }
}

このようにして、アプリケーションを再デプロイすることなく、セキュリティ ルールを一元的に構成および更新できます。さらに、「構成よりも規約」の考え方に適合します。

このアプローチに何か問題がありますか？なぜそれが悪い習慣と見なされるのかわかりませんか？誰かがこれで具体的なセキュリティの問題を示すことができますか?

4

1 に答える 1

1

コントローラーファクトリー内の単一責任の原則に違反しているため、これは悪い習慣だと思います。コントローラ ファクトリの唯一の責任は、コントローラを選択してインスタンス化することです。

コントローラーファクトリーアプローチを採用する理由を質問します。

このようにして、アプリケーションを再デプロイすることなく、セキュリティ ルールを一元的に構成および更新できます。

AuthorizeAttributeコードで許可されたユーザー/ロールを指定する標準を使用する場合、これは有効なステートメントです。

ただし、AuthorizeAttribute保護されたAuthorizeCore()メソッドをオーバーライドすることにより、セキュリティ ルール ロジックから派生し、派生クラスで実装することをお勧めします。たとえば、データベース内の権限を検索して、実行時に動的に変更できるようにすることができます。

これにより、承認チェックが失敗したときに呼び出されるカスタム ロジック (メソッド) を実装することもできますHandleUnauthorizedrequest()。これはおそらく、承認ロジックが失敗したときにカスタム コントローラー ファクトリで実行する必要があることです (たとえば、サインオンまたはエラー ページにリダイレクトしますか? )

そうすれば、アプリケーション全体を再デプロイすることなく、セキュリティ ルールを変更して一元的に管理できるようになります。ControllerFactory

ここで説明されているように、ThinkTexture はアイデンティティ モデル フレームワークで適切な実装を提供します。

http://leastprivilege.com/2012/10/26/using-claims-based-authorization-in-mvc-and-web-api/

これにより、リソース/アクションを指定ClaimsAuthorizationManagerし、通常の WIF の方法で承認ロジックをカスタムにカプセル化できます。リソースとアクションを属性で明示的に指定しない場合、フレームワークは current を使用して から値を取得しますHttpActionContext。これは素晴らしいことです。

于 2013-10-08T16:05:30.853 に答える