5

アプリケーションの公開や共同作業には、多くの場合、リソースへのアクセスの共有が含まれます。ポータルでは、ユーザーは、グループのメンバーとして、または明示的なアクセスのために、特定のコンテンツへのアクセスを許可される場合があります。コンテンツの完全なセットには、パブリック コンテンツ、グループ メンバーシップ コンテンツ、およびプライベート ユーザー コンテンツを含めることができます。または、共同アプリケーションを使用して、ワークフローの一部としてリソースを渡したり、編集目的でドキュメントの管理を共有したりしたい場合があります。

ほとんどのアプリケーションはこれらのリソースをデータベースに保存するため、通常は「編集できるすべてのドキュメントを取得する」または「表示できるすべてのコンテンツを取得する」などのクエリを作成します。「編集可能」と「閲覧可能」はユーザーの権限です。

2 つの質問があります。

  1. リソースを取得したら、ユーザーを承認するのは非常に簡単ですが、使用可能なリソースのリストに対して効率的に承認を行うにはどうすればよいでしょうか? と、

  2. この種の承認は、アプリケーションのコアから分離できますか? おそらく別のサービスに?分離したら、「Get me all the documents I can see with title like [SomeSearchTerm]」のようなクエリをどのようにフィルタリングできますか? あなたの別のシステムは、多くの参照データをコピーする必要があるようです。

4

3 に答える 3

5

Steffen Bartsch によるこの記事を読むことに興味があるかもしれません。Ruby on Rails のすべての認証プラグインを要約しており、解決策を見つけるのに役立つと確信しています (この記事は Rails プラグインに関するものですが、概念は Rails の外に簡単にエクスポートできます)。

Steffen は、「Declarative Authorization」と呼ばれる独自のプラグインも構築しました。これは、ニーズに一致するようです。IMHO:

  • 一方では、役割を定義します(「訪問者」、「管理者」など)。ユーザーはこれらの役割に (多対多の関係で) 関連付けられていますこれらのロールを特権にマップします(ここでも多対多の関係にあります)。各特権は、特定のコンテキストにリンクされています。たとえば、役割「訪問者」は「ドキュメントを読む」権限を持っている場合があります。この例では、「read」が権限であり、「documents」コンテキストに適用されます。
    • 注: Steffen のプラグインでは、ロールの階層を定義できます。たとえば、「global_admin」ロールに「document_admin」ロールや「comment_admin」ロールなどを含めたい場合があります。
    • 特権の階層を定義することもできます。たとえば、「管理」特権には、「読み取り」、「更新」、「追加」、および「削除」特権を含めることができます。
  • 一方、ロールではなく、特権コンテキストの観点から考えてアプリケーションをコーディングします。たとえば、ドキュメントを表示するアクションは、ユーザーが「ドキュメント」コンテキストで「読む」権限を持っているかどうかのみを確認する必要があります (ユーザーが「訪問者」ロールまたはその他のロールを持っているかどうかを確認する必要はありません)。これにより、コードが大幅に簡素化されます。これは、承認ロジックのほとんどが別の場所で抽出されているためです (おそらく他の誰かによって定義されていることもあります)。

ユーザー ロールの定義とアプリケーション レベルの権限の定義をこのように分離することで、新しいロールを定義するたびにコードが変更されないことが保証されます。たとえば、コントローラーでアクセス制御がどのように見えるかは次のとおりです。

class DocumentController [...]
  filter_access_to :display, :require => :read
  def display
    ...
  end
end

そしてビュー内:

<html> [...]
  <% permitted_to?(:create, :documents) do %>
  <%= link_to 'New', new_document_path %>
  <% end %>
</html>

Steffen のプラグインでは、オブジェクト レベル (行レベル) のアクセス制御も可能です。たとえば、「document_author」などのロールを定義して、「 documents 」に対する「manage権限を付与したい場合がありますが、これはユーザーがドキュメントの作成者である場合に限られます。このルールの宣言は、おそらく次のようになります。

role :document_author do
  has_permission.on :documents do
    to :manage
    if_attribute :author => is {user}
  end
end

それだけです!次のように、ユーザーが更新できるすべてのドキュメントを取得できるようになりました。

Document.with_permissions_to(:update)

manage」権限には「update」権限が含まれているため、現在のユーザーが作成者であるドキュメントのリストが返されます。

もちろん、すべてのアプリケーションがこのレベルの柔軟性を必要とするわけではありませんが、あなたの場合はそうかもしれません。

于 2008-11-23T02:27:30.193 に答える
0

私は一般的にこのようなスキーマを持っています

ユーザー---∈UserDocuments∋---ドキュメント

次に、ビュー「ProfiledDocuments」を作成します

SELECT <fields> 
FROM Documents d 
INNER JOIN UserDocuments ud on ud.DocumentId = d.Id 
INNER JOIN Users u ON u.Id = ud.UserId

次に、常にUserIdフィルターを使用してProfiledDocumentsで検索クエリを実行します。適切なインデックスがあれば、十分に機能します。

より複雑なアクセス許可が必要な場合は、アクセス許可の種類を指定するUserDocuments多対多テーブルの追加フィールドを使用して行うことができます。

于 2008-10-04T16:36:47.643 に答える
0

あなたの質問は非常に詳しく説明されていますが、実際にはいくつかのコンテキストが欠落しています。
ユーザーが権限を持つドキュメントを定義するものは何ですか? ユーザーは自分の「自分の」ファイルしか編集できませんか? ここに役割ベースのメカニズムはありますか? より MAC 志向ですか (つまり、ユーザーはセキュリティのレベルを確認できますか)? データを定義する属性 (部門など) はありますか?

これらすべての質問を一緒にすると、より良い全体像が得られ、より具体的な答えが得られる可能性があります。

ドキュメントが特定のユーザーによって「所有」されている場合は、非常に簡単です。ドキュメントの「所有者」フィールドがあります。次に、ユーザーが所有するすべてのドキュメントをクエリします。
同様に、アクセス権を持つ名前付きユーザー (またはロール) のリストを事前に定義できる場合は、ドキュメント間の結合リスト、承認されたユーザー/ロールのリスト、およびユーザー (またはそのロール) を照会できます。
ユーザーが自分の部門 (または他の同様のドキュメントの属性) に従ってアクセス許可を取得する場合は、それについてクエリを実行できます。
同様に、ユーザーの権限レベル以下のセキュリティ レベルを持つすべてのドキュメントをクエリできます。これが動的なワークフローである場合、通常、各ドキュメントは現在の状態および/または次に予想されるステップでマークされている必要があります。どのユーザーがその次のステップを実行できるかは、単なる別の特権/役割です (上記と同じように扱います)。
次に、もちろん、それらすべてと公開ドキュメントの間で UNION ALL を実行する必要があります...

ところで、私が明確にしていなければ、これは単純な問題ではありません. 承認スキーマを簡素化することを犠牲にしても。

于 2008-10-05T00:48:09.167 に答える