3

私は、システム内で特定の役割またはユーザーに許可されていることをカスタマイズできる、柔軟で適度にきめ細かいセキュリティ システムに対する広範な要件を持っています。

この要件に直面して、セキュリティがビルディング ブロックとして使用するアーキテクチャ内のオブジェクト、クラス、またはアイテムを選択する必要があります。ロールが X へのアクセスを許可した場合、X とは何ですか? エンティティ、コントローラー アクション、オブジェクトのカスタム リスト内の項目など。

私が検討しているオプション：

1) エンティティに対する CRUD アクションによる付与 (たとえば、アカウント エンティティへの作成/読み取り/更新アクセス権、請求書エンティティへの読み取りアクセス権などをユーザーに付与できます)

2) エンティティに対する CRUD アクションによる付与、個々のエンティティ プロパティに対する RU アクション (たとえば、特定のフィールドを更新するためのアクセス) - エンティティの属性によって識別される「プロパティ グループ」を使用して簡略化できます。

3) リポジトリ & リポジトリ機能による付与 (例: AccountsRepository.Get(...) または AccountsRepository.GetList(...) の呼び出しを許可)

4) MVC コントローラーによる付与 + アクション (例: /Accounts/Index または /Accounts/Update/X などへのアクセスを許可)

5) アーキテクチャ内の任意のものに関連付けることができる「セキュリティ オブジェクト」のカスタム リストによる付与

オプション (5) は柔軟性が最も高くなりますが、実装の汎用性は低くなります。オプション (4) は、セキュリティ項目がユーザー インターフェイスを厳密に反映するため魅力的ですが、ドメインがアクセスを保護しておらず、セキュリティが Web 以外のインターフェイスに適用されないことを意味します。

MVC + DDD + リポジトリ パターンでセキュリティ パターンを設計したあなたの意見と経験は何ですか?

4

3 に答える 3

1

これは、セキュリティ フレームワークの設計者が、認証の問題の分野でどのような機能を提供できるかを考えるときに自問する質問の 1 つだと思います。

プラットフォームで利用可能な実際のセキュリティ フレームワークの設計または実装を確認することをお勧めします。

私が知っているのは、Java ベースの Spring Security と Apache Shiro だけです。

通常、すべての承認要件に対応する機能が付属しており、質問のように、あらゆるレベルの粒度でソリューションを提供できます。

  • リソース レベル (セキュリティ チェックを適用するオブジェクト インスタンスに関心がない場合)。
  • インスタンス レベル (オブジェクトの特定のインスタンスへのアクセスを制御します)。
  • 属性レベル (オブジェクトの特定のインスタンスの特定のフィールドへのアクセスを制御します)。
于 2013-10-28T09:35:35.127 に答える
1

最も一般的なセキュリティ メカニズムは、ロールとリソースのみを必要とします。この場合、オプション (4) は私が見た中で最も一般的なソリューションのようです。したがって、プラットフォームには成熟したセキュリティ フレームワークがいくつかあるはずです。

セキュリティの粒度がドメイン オブジェクトにある場合、セキュリティの要素が必然的にドメイン モデルに混在します。通常は不要だと思います。

一方で、一部のセキュリティ要件にはビジネス コンテキストが必要です。たとえば、オペレーターは 1000 ドルを超える取引を操作することはできませんが、スーパーバイザーは操作できます。正直なところ、これを実装する方法については経験がありませんが、個人的には、コア ドメインから別の境界付けられたコンテキストでセキュリティ実装を構築することを好みます。

于 2013-10-27T12:20:14.873 に答える