承認は階層化アーキテクチャのどこに適合しますか？

通常、サーバー側のコントローラーに承認の決定を下します。これらは最近RESTfulエンドポイントになりましたが、MVCタイプのアーキテクチャも同じものだと思います。議論のために、それは役割ベースの承認であると仮定します。保護されたメソッドには注釈が付けられるか、チェックが行われ、必要に応じて403が返されます。

さて、承認が実際にはビジネスルールであることを考えると、たとえば「管理者だけがXをリストできる」ということを考えると、私は彼らがレイヤーを押し下げられるべきだと考えています。コントローラーがビジネスレイヤーに操作の実行を要求すると、サービスまたはビジネスレイヤーは、コントローラーに許可されていないことを通知します。

これは合理的なアプローチですか？これには欠点はありますか？

これを行うための静的な手続き型のコード化されたルールを本質的に保持するAuthorisationServiceがあるのは嫌ですが、すべてのアクセスロジックを1か所に保持することは理にかなっています。それは別々に保たれるべき横断的な関心事ですか？

だから私は誰かがこれをやったかどうか、彼らがそれをどのようにきれいに達成したか、または私が読むことができる良いリソースがあるかどうかを尋ねています。Java fwiwを使用していますが、これは言語に依存しない質問です。

ここで関連する質問を確認しましたが、それらは非常に薄いので、答えはありません。例：ドメインモデルでの検証と承認、およびサービスレイヤーを介したMVCへの実行

私は春のセキュリティ文書を読んでいますが、それは横断的な関心事であるといくつかの良い議論をしていますが、それは単なる「春の道」であり、より広い視野が欲しいと心配しています。また、アプリケーションを特定のフレームワークに結び付けます。

ユーザーが許可されているオプションのみを公開することをお勧めします。

これにより、承認が強制的に横断的な関心事になります。「ビュー」は、表示用のオプションとメニューを作成する前に、ユーザーが許可されていることを知る必要があります。

バックエンドはフロントエンドを信頼してセキュリティの決定を行うべきではないため、承認自体を確認する必要があります。

データに応じて承認に影響するビジネスルールがある場合があります。たとえば、「5000ドルを超える残高を持つユーザーのみが外貨送金を呼び出すことができます」または「本社にいるユーザーのみがこれらのアカウントを表示できます」。そのため、ビジネスロジック内でいくつかの承認ロジックが必要です。

考慮すべき技術的な承認もあります-ログの閲覧を許可されているユーザー、データベースをバックアップ/復元できるユーザーなど。

そのため、最終的にはすべてのコンポーネントに特定のセキュリティおよび/または認可要件がありますが、実際にはこれを個別の「認可層」にまとめることはほとんど不可能です。

サービス層に認可を埋め込むことは絶対に合理的なアプローチだと思います。不正なアクティビティ（特にデータ変更）を実行することからサービスを保護する必要があります。サービスレイヤーを1つのライブラリに配置し、異なるプレゼンテーションレイヤーで使用することができます（同じサービスレイヤーを使用する異なるUIアプリケーションを持つことができます）。また、特定のプレゼンテーションレイヤーが必要な検証を実行するという事実に頼ることはできません。これは、後でサービス層を別のプロセスに移動することを決定する場合（たとえば、SOAアプローチに従って）に特に重要です。

次に、「クリーンな方法」でこれを達成する方法について説明します。承認チェックでビジネスロジックを散らかすという考えが好きではないので、アスペクト指向プログラミングアプローチの特定の実装が役立ちます。サービスメソッドを特別な属性で装飾したり、インターセプトで動的プロキシを使用したりすることができます。

そして重要なことは、非常に単純なプロジェクトでは、あなたの人生を単純化するために、別々の検証なしで生きることができることを認める必要があります。しかし、「シンプルなプロジェクト」が「複雑なプロジェクト」になり始めた瞬間をお見逃しなく。

承認チェックをできる限り低くするのが好きです！（しかし、それ以上はありません！）

これよりも上のレイヤーに対する自動認証テストを自由に作成できます。また、一部のルールは、サービスレイヤー（CanView / CanSerialize？）などの上位レイヤーでのみ適用または意味がある場合があります。しかし、私は一般に、最も安全な承認戦略は「DRY-est」戦略でもあると考えています。できる限り「共通」または「共有」コードで（認証ルールを過度に複雑にすることなく）承認をできるだけ低くします。

代替案について考えてください。承認規則がサービスレイヤーでのみテストおよび実施され、貧弱なドメインオブジェクトが不機嫌なサービスオブジェクトの意志に委ねられている場合、多くの場合、複数のオブジェクトおよび複数の個々の規則を複数回実施する必要があります。各オブジェクト、およびより複雑なコードに配置します。

さらに、分析チームがドメインオブジェクトを使用してレポートサービスを作成するためにコンサルティング会社を雇う場合、それらの開発者を信頼する必要はありません！（または任意のあなたのために同じオブジェクトに対する追加のサービスや通話を構築する。何らかの理由で。）あなたは、ビジネスルールとの大きな本オープンクラックするとは思わないだろう希望を適切にそれらのルールを強制するためにもう一度。ドメインにそれらを既に知ってもらい、それらを強制する必要があります。