8

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

私が見た多くの例では、Authorization は別のサービスに配置されています。多くの場合、個々のクエリに使用できる isAuthorized() に似たメソッドを公開するものです (「ユーザーはリソース ABC を使用する権限がありますか?」)。バルク クエリ (「ユーザーは次のリソース リストのいずれかを使用する権限がありますか?」)。

認可ロジックは認可サービスに存在しますが、認可ポリシーの施行はアプリケーション自体の内部に保持されます (たとえば、認可サービスからの結果に基づいて、リソースへのアクセスを実際に実装するためのビジネス ロジック層、またはプレゼンテーションAuthorization Service からの結果に基づいて個々のオプションを表示/非表示にするレイヤーなど)。

たとえば、データ アクセス レイヤーに何十億もの "リソース" が返される可能性がある場合、どのような方法が望ましいでしょうか? 私のビジネスロジックレイヤーはそのすべてのデータを照会し（すべてをネットワーク経由で渡します）、その巨大なリストを承認サービスに転送します（再びネットワーク経由で）。「許可/拒否」の巨大なリストを取得するだけですかビジネスロジックに送り返されますか？明らかに、それは正しく聞こえません。

これは、データ アクセス、承認ロジック、およびビジネス ロジックを「明確に」分離できない場合ですか? 代わりに、データアクセス層に、ユーザーがアクセスできるすべてのリソースのリストのみを返すように依頼する必要があります。これは、単純なデータベース結合として実装される可能性がありますが、誰が誰であるかを判断するためのロジックの一部が必要になります。どの条件の下でどのリソースにアクセスできるか (つまり、承認ポリシー) がデータ アクセス コードに埋め込まれているため、これらのポリシーはコード ベース全体に分散されます (たとえば、一部の承認ロジックは Data-Access に含まれます)。レイヤー、一部は私の認証レイヤーにあるなど）？

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

4

3 に答える 3

1

認証は外部化された方がよい。多くの場合、承認はアプリケーションに依存しすぎて外部化できません。小さなシステムではうまくいくかもしれません。しかし、大規模なシステムでは、すでに予想されているように、スケーリングの問題が発生します。

もう 1 つのことは、巨大なデータセットを返すことです。私には、これは報告に適しているように思えます。したがって、最初のプロセス モジュールを、異なる要件を持つレポート モジュールから分離します。これは、ビジネス プロセスでは焦点を絞ったデータが必要であり、大量のデータと抽象化をレポートする必要があるためです。

承認はレイヤーではありません。それは側面です。少なくとも適切なモックに置き換えないと、レイヤーがないとアプリケーションが機能しない可能性があります。しかし、アスペクトを削除すれば、アプリケーションの実行に問題はありません。おそらく、あなたのプログラムは何もログに記録しないか、許可されているよりも多くのデータを見ることができますが、それでも機能します.

では、承認はアプリケーション ドメインから外部化する必要がありますか? いいえ。ビジネス ロジックから分離する必要がありますか。はい。適切なメカニズム: アスペクト (AspectJ、Proxy-Pattern、Template-Class-Pattern)。これは私の一般的な提案です。

ビジネス プロセスにおける「大量のデータ」に対する私の特別な提案は次のとおりです。次に、私の一般的な提案に戻ります。

ビジネス プロセスで大量のデータを処理する必要がある場合は、「機能させる」「正しく機能させる」の最後のポイントを使用します。遅い、または遅いことが予想される特別なデータ要求の最適化と考えてください。この場合、特別な sql クエリ、プリロード、キャッシングなどを使用します。DAO 層は適切な場所、キャッシングの側面、または DAO 層の最適化の側面であり、「動作が遅い」実装を代替実装でオーバーライドします。速い。

私が行った提案は、通常のビジネス ユース ケースに言及したものです。私はビッグデータやレポートについて話しているのではありません。前述したように、これらのセクターには異なる要件があります。

于 2015-05-09T17:29:00.847 に答える
0

あなたの質問に対する決定的な答えはありませんが、いくつかの指針を提供できるかもしれません-

  • あなたが尋ねた

    私のビジネス ロジック レイヤーは、そのすべてのデータを照会し、その巨大なリストを認可サービスに転送して、ビジネス ロジックに送り返された「ALLOW/DENY」の巨大なリストを取得するだけですか?

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

  • サービスとの間でレコードの識別子を渡すだけである可能性が最も高いという事実に加えて、このアプローチが実行可能であることがわかるかもしれません。

  • また、承認ロジックを「サービス」として持つことは、必ずしも別のマシンに存在する必要があることを意味しないことに注意してください。これを別の論理モジュールとして実装し、同じマシン上で (必要に応じてアプリケーションと同じプロセス上で) 実行できるため、ネットワーク トラフィックの問題を回避できます。

  • データアクセスの一部として承認を実装するのは難しいというあなたの観察は正しいです。ただし、それを支援するインフラストラクチャ ツールがいくつかあります。たとえば、Oracle の仮想プライベート データベース、(n) hibernate フィルターなど、他にもあると思います。

繰り返しますが、これらは完全な回答ではありませんが、あなたにとって有効な解決策につながる可能性があります。
「承認フレームワーク+ [お気に入りのプログラミング言語]」をグーグルで検索することをお勧めします。私は誰かがすでにそれをやったと確信しています:)

于 2012-12-02T22:00:38.650 に答える
0

私は、実際の経験に基づいていない初期のアイデアを持っていますが、一見するともっともらしいです。

なぜ認証サービスがあるのですか? 私の主張は、データ ソースが完全な仕事をしていないため、そのサービスのいくつかの機能があるということです。データのソースとして RDBMS データベースのみを使用している場合、データベースは主要なカテゴリの承認を取り締まる可能性があります。ビューに対して作業し、それらのビューにアクセスする権限を付与して、必要に応じてテーブルと列を保護できます。この種のルールのセットが残っています

従業員の給与情報は、a) に表示できます。従業員、b）。彼らのマネージャーとセカンドラインマネージャー、c)。人事報酬チームのメンバー。

このような承認規則にはビジネス セマンティクスがあり、承認サービスによって実装するのが最適であり、そのサービスの表現はビジネス オブジェクトの観点からだと思います。

 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
于 2013-04-19T10:15:34.827 に答える