2016-08-31 13 views
1

Neo4jを使用するアプリケーションで階層的にアクセスポリシーを定義する必要があります。neo4jでカスタムユーザーアクセス許可を実装する方法は?

モデル:アプリケーションは、ツリー構造を使用して(各Nodeは、ちょうど1つの親を持っている)、簡略化のため

(:Node)-[:SUBTREE_OF]->(:Node) 

として表すことができます。

Userのメンバーは、Groupのメンバーであり、Permissionsです。アクセス権には、アクセス許可が設定されているオブジェクトのIDを含むobjectIdWRITEREADまたはNONEのいずれかのという2つのプロパティが含まれています。

ので

(u:User)-[:MEMBER_OF]->(g:Group) 
(g:Group)-[:WITH]->(p:Permission{objectID:"99", accessLevel:"WRITE"}) 

問題:すべての子によって継承できるオブジェクトのための可能な指定許可のアクセスレベルを確認する必要があります。これは、特定のアクセス権レベル、具体的にはUserを実行時に特定する必要があることを意味します。アクセス権が指定されていない場合はこのオブジェクトに最も近い指定された親アクセス権を指定します。

プロパティが指定されたNodeまたは最も近い親Nodeを返すクエリを書き込む方法はありますか?

+1

a:PermissionのobjectIDが参照するオブジェクトは、ツリー構造のノードと同じですか?パーミッションがツリー構造内のノードを直接対象としている場合:パーミッションは以下のものの一部にすぎません:グループ、グラフをリファクタリングして簡単にクエリを実行できる機会がいくつかあります。また、次のようにします:Permissionオブジェクトは、objectIDとaccessLevelだけを格納するか、他のフィールドはありますか? – InverseFalcon

+0

@InverseFalconオブジェクトには、次のものがあります。アプリケーションとノード: :アプリケーションは親のためのものです:Node's、しかし私は単純化のためこれを省略することにしました。 :アクセス権はObjectIDとaccessLevelだけを格納します。 – Polyakoff

+1

さて、意味があります。 a:ノードに関連付けられていない場合:a:グループからのアクセス許可:グループの場合、アプリケーションは保証されますか?または上記の他のノードタイプがありますか?アプリケーションには:許可が必要ですか?存在しない場合に使用する必要のある既定のアクセス許可がありますか?階層上の任意のノードに対してアクセス許可が存在しますか? – InverseFalcon

答えて

3

は今、あなたの:Permissionsは、オブジェクトIDプロパティによって:Nodes:Applicationsに関連付けられているが、グラフの関係を使用して効果的なクエリのために、これはおそらく、オブジェクト自体との関係としてモデル化する必要があります。この時点でaccessLevel:Permissionノードに格納するか、:Permissionノードを完全に取り除き、:HasPermissionの関係をaccessLevelというプロパティでモデル化するかどうかの問題です。

ここでは、:Permissionのノードをそのまま使用したいと考えています。 :Userだけ:Node(またはその:Node先祖)の許可を得るために1 :Groupのメンバー、クエリできると仮定

のようなものになり:ノード:

MATCH (:User{ID:123})-[:MEMBER_OF]->(group:Group), (node:Node{ID:123}) 
WITH group, node 
// looking for a :Node going up the chain with a permission from your group 
OPTIONAL MATCH (node)-[jumps:SUBTREE_OF*0..]->(target:Node)<-[:HasPermission]-(perm:Permission)<-[:WITH]-(group) 
WITH node, target, perm, jumps 
ORDER BY SIZE(jumps) LIMIT 1 
RETURN target, COALESCE(target = node, false) as same_node, COALESCE(perm.accessLevel, "WRITE") as accessLevel 

リターンはtargetを含み最終的に一致しました(階層内に見つからない場合はnullになり、 "WRITE"アクセスレベルにデフォルト設定されています)。same_node:許可を得たいNodeが許可を得たかどうか(falseは許可または既定の祖先を見つけたことを意味します)、accessLevelはthですe関連するアクセス権のアクセスレベル。おそらくこれらのすべてを必要とするわけではありませんが、テストが正しく機能していることは有益です。

EDIT

我々は簡単に私たちはチェーンを横断する関係の数でソートすることにより、あなたのグループ権限を持つ最も近い親ノード(またはノード自体)を選択する順序を強制することができることを思い出しました。これを処理するために上記のクエリを変更しました。

+0

別のノードでもアクセスのレベルが必要だと思います。 –

+1

暗黙的な順序付けに頼るのではなく、私は自分のクエリを編集して順序付けを行い、最初のノードを常にグループ権限を持つチェーンにつかみます。 – InverseFalcon

+1

@InverseFalcon更新されたクエリは、次の場合にも有効です。ユーザーが複数のグループに属している場合。それは私の問題を解決する、あなたの時間をありがとう。感謝します。 ID()関数を使ってクエリを少し更新してくれました。http://pastebin.com/DqBPnWH2 – Polyakoff

関連する問題