RBAC は RBAC ではありません RBAC は RBAC ではなく、RBAC は紙の上では難しいですが、実際に実装することはほぼ不可能です。
誰もが独自の RBAC の "アイデア" を持っており、ほとんどの人が RBAC に関連するすべてのものに対して異なる用語を使用しています。一般に、LDAP 実装の観点からすると、LDAP 内で適切な実装を行うためのすべての「部品」を持っていることはめったにありません。
簡単に言えば、「ピースパーツ」は次のとおりです。
S = 件名 = 人、自動エージェント、またはユーザー
P = パーミッション = ターゲット リソースへのアクセス モードの承認
T = ターゲット リソース = 権限を割り当てるオブジェクト
役割は、少なくとも、権限とユーザーを関連付ける必要があります。ターゲット リソースは、完全に LDAP の外部にある可能性があります。したがって、Tomcat サーバー上のアプリケーションである可能性もあれば、単に LDAP サーバー内の「その他の」エントリを読み取る権利である可能性もあります。
したがって、通常、LDAP 内で行う最善の方法は、ユーザーのリストを持つオブジェクトをセットアップし、LDAP 内にリソースがいくつかある場合は、それらのターゲット リソースに適切なディレクトリ アクセス許可を割り当てることです。
次に、小さな問題の実装があります。
役割を実装するためのポリシーが必要になりました。したがって、私たちの役割は、USER-READ-ONLY と呼びますが、それがどのように使用されるかについてのポリシーがなければ役に立ちません。
この場合、USER-READ-ONLY ロールは組織内のすべてのものを読み取ることができると言えます。
これでポリシーができました。このポリシーはどこに保存されますか? ポリシーのデジタル表現は、「ポリシー情報ポイント」または PIP に保存されます。
PIP から提供されたポリシーをどのように解釈しますか? ポリシーは、ポリシー決定ポイント (PDP) によって解釈されます。
サブジェクト (ユーザー) がリソースにアクセスできるかどうかを決定するのは誰ですか? ポリシー施行ポイント (PEP)。
このすべてのポリシーをまとめると、最終的にポリシーのデジタル表現が得られます。ポリシーは、ポリシー情報ポイントによってポリシー決定ポイントに提供されます。ポリシー決定ポイントは、アクセスが許可または拒否されるポリシー施行ポイントに決定を渡します。
では、RBAC の話では、PIP、PDP、および PEP はどこにあるのでしょうか? ターゲット リソースが LDAP ディレクトリにある場合、それは PIP である LDAP ディレクトリです (おそらくハードコードされており、抽象化されていません。PIP も PEP も同様で、簡単でした。
しかし、それが私たちのTomcatアプリケーションである場合、「私にはこのサブジェクト（ユーザー）がいて、彼はこのターゲットリソース（インベントリ）にアクセスしてこの許可を実行することを望んでいます(読み取り専用)".
確かに、これらすべてのものにはいくつかの基準があります。(Google XAML、RFC3198、ISO10181-3、NIST) ですが、これらは実用的な実装には大きなギャップがある標準です。
したがって、RBAC の実際の実装は難しいことに注意してください。
確かに、私たちはRBACについて知り、論文を研究し、それを戦略的な方向性にする必要がありますが、ベンダーとアプリケーションの幅広いベースでの実際の実装は、まだそこに達していません.
-ジム