0

2 つのパラメーターを持つ RBAC システムの例またはベスト プラクティスを探しています。単にユーザーをロールに関連付け、そのロールを権限のグループに関連付けるだけではなく、ユーザーは「特定のプロジェクトの」ロールに関連付けることができ、ユーザーはそのプロジェクトのみ (またはユーザーがそのロールを保持している他のプロジェクト) に対してそのロールの権限を持つことができます。ユーザーは、あるプロジェクトで特定の役割を持ち、別のプロジェクトで別の役割を持つことができます。ロールに付与される権限は、すべてのプロジェクトで一貫しています。また、プロジェクトに対するユーザーの権限は、そのユーザーがプロジェクトで持っている役割に基づいています。

(違いがある場合は、GET ステートメントを介してプロジェクト ID を設定する URL クエリ パラメーターを介してページ コンテンツが開発されるページ アクセスを制限しようとしています。)

ABAC は有望に見えますが、頭を悩ませています。私の理解では、ユーザーの属性によって、ユーザーが役割 (および/または権限) を持っているかどうかが決まります。私の場合、プロジェクトを「ユーザー」と見なし、ユーザーをプロジェクトの属性と見なすようです (ユーザーがそのプロジェクトの役割を保持している場合は true、そうでない場合は false)。

4

1 に答える 1

1

RBAC 標準に固執する場合は、プロジェクトごとに異なる役割を使用する必要があります。たとえば、ロール「admin」がプロジェクト「P1」と「P2」で使用されている場合、ロール「P1:admin」と別のロール「P2:admin」を作成できます。

ABAC は確かに別の可能性です。ただし、私の理解が正しければ、「ユーザーの属性によって、ユーザーが役割 (および/または権限) を持っているかどうかが決まる」というのは正しくありません。ABAC には (ロール属性であるという意味で) 属性のみがあり、RBAC よりも柔軟性があります。リクエストでは、プロジェクトを表す属性 (「P1」または「P2」) と、その特定のプロジェクトのロールを表す別の属性 (「管理者」) を指定できます。正しく指定されたポリシーは、たとえば、「P1」プロジェクトの一部として「管理者」ロールを参照していることを認識できます。

于 2014-01-14T11:58:50.997 に答える