1

私は最近、従来のASP.Net Webフォームベースの開発からMVC2に移行し、MVCが長期的に保守可能なWebソリューションを作成するために活用できるベストプラクティスと規範を探していました。

認証とRBAC（役割ベースのアクセス）の実装に到達しました。以前は複雑さを避けるために単純な静的RBACを使用していましたが、MVCを使用すると、従来のアプローチに対するより優れたオプションとより多くの制御が期待できます。メンバーシップAPIはASP.Netセキュリティのデフォルトですが、多くのDBオブジェクトが必要であり、ユーザーにプロパティを追加したり、デフォルト機能の一部をオーバーライドしたりするなど、動作を簡単に変更する方法もありませんでした。

要約すると、以前は、Membership APIを避け、独自のシンプルなUserserviceレイヤーアプローチを使用して、シンプルなセキュリティとRBACを実現する必要がありました。私はページレベルのアクセス制御を持っていて、すべてのWebフォームページが派生した基本クラス（Pagebase）内からそれを処理しました。ページのセキュリティを構成するには、いくつかのロールパラメータを渡す必要がありました。ユーザーとロールのメンテナンスは非常に簡単で、セキュリティの質問、ハッシュパスワード、ソルトなどは必要ありません。少なくとも今までは必要ありません。

さて、MVCでは-中央制御と同様のものが必要です。コントローラレベルおよび/またはアクションレベルの認証（[認証]またはカスタム）のいずれかを使用できます。「承認フィルター」（アクションフィルターなど）をデプロイできます。ダイナミックRBACにも行きたいです。メンバーシップ機能を使用したいのですが、そのテーブルは必要なく、上記の他の余分なことは避けたいです。

静的メンバーシップAPIベースのアプローチ：役割ベースのセキュリティasp.net mvc

メンバーシッププロバイダーとロールプロバイダーをオーバーライドして、バックグラウンド処理を完全に制御し、その上にあるメンバーシップAPIとRBACの機能を活用できることを学びました。

例えば、

カスタムメンバーシッププロバイダー

ロールプロバイダーの実装

私はここまで来ました。正しい道を進んでいること、そしてこのアプローチによって、管理者レベルのユーザーにRBACを構成するために公開できる動的RBACに徐々につながることを確認したいと思います。これが私の要件です-

  1. Membership APIを使用する価値がMVCで価値があり、デフォルトの実装をオーバーライドできるようになることを願っています。
  2. 余分なテーブルは必要ありません。不要な特別なフィールドがないように、最小限のユーザー/ロールテーブルに保持したいと思います。
  3. 独自のサービスレイヤーアプローチを使用して、DB内のテーブルにアクセスして管理できます。メンバーシップのデフォルトはありません。
  4. 複雑すぎる場合は、今のところ静的RBACで実行できますが、将来的には動的RBACが必要です。
  5. Membership APIを使用する傾向があるのは、それがなければ自分でデプロイしなければならない有用な属性を提供できることがわかったからです。
  6. 乱雑にならないことを願って、私のDAL /サービスレイヤーに従い、コントローラーレベルとアクションレベルのRBACを許可します。

plsは私を導き、あなたの提案を共有します。

編集1： 私はSOからさらにいくつかを見つけました:(私たち自身を展開すると言います）

4

1 に答える 1

1

わあ、1年以上経ちました！

さて、私はカスタムメンバーシッププロバイダーを実装しようとしましたが、それから私はもっとカスタマイズしたいと思い、特定のモデルとアクションのためにもっとアドホックな機能を持ちたいと思いました。

それで、最終的に、私は単純な（しかし非常に効果的な）コントローラーレベルのアクションフィルターを使用することになりました-

public class IsAuthorizeAttribute : AuthorizeAttribute
...
public IsAuthorizeAttribute(Rights rightToAuthenticate)

権利は、権利を宣言するために使用するカスタム列挙型です（ほとんどはコントローラーレベルで関連付けられていますが、アクションレベルでもあるものもあります）。これを単純なテーブル構造と組み合わせると、次のようになります。

  • ユーザー
  • 役割
  • UserRole
于 2012-08-30T14:21:22.813 に答える