認可サービス - 許可されたリソースのリストを返す

Question

ユーザーがアクセスできるすべてのリソースのリストを取得する推奨される方法は何ですか？

私が見てきた多くの例では、認可は別々のサービスに置かれています - 個々のクエリで使用できるisAuthorized（）に似たメソッドを公開するものがよくあります（「ユーザーはリソースABC ？ "）とバルククエリー（"ユーザーは以下のリソースリストのいずれかを使用する権限を持っていますか？ "）。

承認ロジックは、認可ポリシーの執行が結果に基づいて、実際にリソースへのアクセスを実現するために（例えば、ビジネス・ロジック層、アプリケーション自体内に保持され、承認サービスに存在するが認可サービスからの結果に基づいて個々のオプションを表示/非表示するためのプレゼンテーションレイヤーなど）を作成することができます。

たとえば、データアクセス層に何十億という「リソース」が返ってくる可能性がある場合は、これを行うのが好ましい方法は何ですか？私のビジネスロジック層は、すべてのデータを（ネットワークを介してすべてのデータを渡して）照会し、その巨大なリストを認可サービス（ネットワークを介して）に転送し、「許可/拒否」の巨大なリストを取得し、ビジネスロジックに送り返されますか？明らかに、それはかなり正しいとは言えません。

データアクセス、認可ロジック、およびビジネスロジックを「きれいに」分離することはできませんか？代わりに私のデータアクセス層に、ユーザーがアクセスできるすべてのリソースのリストを返すように要求する必要があります。これは単純なデータベース結合として実装される可能性がありますが、 （つまり、認可ポリシー）がデータアクセスコードに埋め込まれているため、それらのポリシーは自分のコードベースに広がります（たとえば、認可ロジックがデータアクセスレイヤー、いくつかは私の認証レイヤーなどにあるでしょうか？）

パフォーマンスは「クリーン」アーキテクチャよりも優先されるかもしれませんが、これを行うにはより良い方法がありますか？

Answer 1

私はあなたの質問に明確な答えを持っていないが、私はいくつかのpointers-

• を提供することができるかもしれあなたは
  

  を尋ねた私のすべてのビジネスロジック層の問い合わせをいそのデータを転送し、承認サービスにその巨大なリストを転送する 、唯一の巨人 のリストを取得する "許可/拒否"ビジネスロジックに返信？

まあ、それは本当に私にとって可能性の高いシナリオのようには見えません。 すべてユーザーに利用可能なレコードを提示したいと思う状況を考えることはできますか？これらのレコード（タイプ、日付など）をさらにフィルタリングする方が合理的ではないでしょうか？また、ユーザーが一口サイズの結果セットを取得できるように、それらをページしたいと思うかもしれません。

• 最も可能性が高いあなただけのサービスにしてから、レコードの識別子を渡しているはずだ、あなたはこのアプローチがあなたのためになんとかであることを見つけることが事実にそれを追加します。

• 認可ロジックを「サービス」として使用しても、必ずしも別のマシンに置く必要があるわけではありません。別の論理モジュールとして実装しても、同じマシン上で実行することができます（必要に応じて、アプリケーションと同じプロセス上にある可能性があります）。そのため、ネットワークトラフィックの問題を回避できます。

• データアクセスの一部として認可を実装するのが難しいというあなたの見解は正しいです。しかし、それに役立つインフラストラクチャツールがいくつかあります。例えば、オラクルのvirtual private database、(n)hibernate filtersなどがあります。

また、これらは完全な回答ではありませんが、あなたの役に立つ解決策につながる可能性があります。
私はあなたにGoogleの認証フレームワーク+ [お気に入りのプログラミング言語]をお勧めします。私は誰かが既に前にそれを済ませていると確信しています:)

Answer 2

私は胚のアイデアを持っていますが、実用的な経験に基づいていませんが、一見それはもっともらしいです。

なぜ認可サービスを持っていますか？私の主張は、私たちのデータソースが完全な仕事をしていないので、そのサービスのいくつかの機能を持っているということです。データのソースとしてRDBMSデータベースのみを使用していた場合、データベースは主要なカテゴリの認可を脅かす可能性があります。ビューに対して作業を行い、それらのビューにアクセスするための権限を与えて、テーブルやカラムを望みどおりに保護することができます。この種のルールが残っています。

従業員の給与情報をa）に示すことができます。従業員、 b）。マネージャーとセカンドラインマネージャ、c）。 HR 報酬チームのメンバー。私は、このような承認規則は、ビジネスの意味を持ち、そして最高の認証サービスとそのサービスの発現によって実装されていることを信じてい

ビジネスオブジェクトの観点である。それは、用語で表現されていない

can This employee see That employee's salary? 

テーブル、行、および列の、より粗い、ビジネスに意味のある粒度である。これを実装するには、認可ルールを表すデータモデルを構築する必要があります。厳密にはビジネスロジックですが、実装をカプセル化する認可サービスをリファクタリングするだけです。

ビューとテーブルとカラムの観点から表現された細かいエンティティ認証とは対照的です。私の主張は、これがデータソースに適切に属し、データソースがそれを実装できない、または実装していない場合は、データアクセスレイヤに実装する必要があるということです。 DAOは、どのビュー/テーブルを使用しているかを「知って」おり、おそらく要求が実行されているIDを知っているため、アクセスが許可されているかどうかを判断します。

DAOはSQLを持っているので、エンティティを知っているので、決定できます。 （あるバックエンドにはSQLが存在しないかもしれませんが、DAOは何が取得されているのかを理解するオブジェクトです）。特定のユーザーに対してどのアクセスメソッドが許可されているかをリストするメソッドを追加することができます。

CustomerDAO.whatIsAuthorised("joeCoder") => READ, QUERY 

CustomerDAO.whatIsAuthorised("phb") => READ, QUERY, UPDATE 

Answer 3

認証は外部化する方が良いです。認可は、しばしばアプリケーションを外部化することにも依存します。それはほとんどシステムのために働くかもしれません。しかし、大きなシステムでは、すでに予想されているようにスケーリングの問題が発生します。

もう一つは、巨大なデータセットを返しています。これはレポート作成に適しているようです。したがって、ビジネスプロセスでは、集中したデータが必要であり、大量のデータと抽象を報告する必要があるため、レポートモジュールとは異なる最初のプロセスモジュールと要件が異なります。

認可は、層ではありません。それは一面です。あなたが少なくとも適切なモックに置き換えないと、レイヤーなしでアプリケーションが動作しないことがあります。しかし、アスペクトを削除する場合は、アプリケーションを実行する際に問題はないはずです。あなたのプログラムは何もログに記録しないか、あなたが見ることができるよりも多くのデータを見ることができるでしょうが、それでも動作します。

だから許可はアプリケーションドメインから外部化すべきか？いいえ、それはビジネスロジックから分離されるべきですか？はい。適切な仕組み：Aspects（AspectJ、Proxy-Pattern、Template-Class-Pattern）これは私の一般的な提案です。業務プロセスの「巨大なデータ」の

私の特別な提案は次のとおりです。少し集束データ（件名「ユーザビリティ」または「ユーザーエクスペリエンス」）を持つように適切にあなたのドメインモデルを分割するようにしてください。その後、私の一般的な提案に戻ります。

あなたはビジネスプロセスにおけるデータの膨大な量に対処しなければならない場合：「それは右のそれは、高速作る作る動作させる」の最後のポイントを使用してください。特殊なデータリクエストの最適化と考えてください。遅いことが予想されます。この場合、特別なSQLクエリ、プリロード、キャッシングなどを使用します。DAOレイヤは、適切な場所、キャッシング・アスペクト、またはDAOレイヤの最適化アスペクトである可能性があります。速い。

私は通常のビジネスユースケースを参照して作られた提案。大きなデータや報告については言及していません。私が言及したように、これらのセクターは異なる要件を持っている