2009-05-25 6 views
0

現在、多くのユーザーに異なるアクセス権があるリソースに対して、ロールベースの認証システムを設計しています。スケーラブルな役割ベースの認証

ロールは、単一のユーザーまたはロールのグループ(ロールはロールのツリーなので)です。

The other image here

(下図を参照)リソースは、このそれぞれの操作へのアクセスを行うために許可されたロールのリストで複数の認証プロパティを(のような、読み取り、書き込み、削除)、持つことができます。問題は、私は、ユーザーがプロパティにアクセスする権利を有するかどうかを確認したい場合は、私は最悪の場合にはn個の木をトラバースする必要がある(ここで、nはロールの数です

Image goes here

(下図を参照)プロパティに割り当てられます)。

たとえば、 'Max'がプロパティを読み取ることができるかどうかを確認するには、マーケティング、管理、および管理ツリーに「Max」が含まれているかどうかをチェックする必要があります。


では、ロールシステムまたは同等に強力な何かを維持しながら、非常に高価なツリー検索を除去する任意のアルゴリズムまたは別のアプローチを知っていますか。

n個のロールの場合、O(log(n))のようなルックアップが最適なケースです。

おかげで、 Fionn

+0

私が見る限り、機能要件/仕様の説明にはツリーが含まれています。したがって、仕様を変更するか、ツリーの検索が「非常に高価」になるのを防ぐ方法を見つける必要があります。 – ChrisW

答えて

2

これを測定し、このトラバーサルはパフォーマンスのボトルネックですか?

私はこの種の構造を横断するコストが非常に多くのロール/レベルを持つシステムを見たことはありません問題となる。ツリーが本当に大きければ、管理者が誰に何をする権限があるのか​​を理解することが難しくなることが懸念されます。

スケーラビリティに関しては、通常ASP.NETキャッシュを使用して、適切なキャッシュタイムアウトを使用して、リソースとロール間をマッピングする完全なツリーをキャッシュします。また、ユーザーからロールへのマッピングを別々にキャッシュします(セッションやASP.NETキャッシュ内のユーザー固有のキーなど)。

キャッシュからの情報へのアクセスは、通常、毎回データベースにアクセスするのと比べて非常に高速です。

0

あなたがSQLデータベースに自分の役割を置く場合で説明するように、ルックアップは、実質的に実行されます。私が興味を持っているなら、データベース構造についてお手伝いします。

+0

SQLデータベースは、ツリーのトラバーサルの複雑さを本当に取り除くことはできません。逆に、私の意見ではSQLのツリーは非常に苦痛です。 役割の深さは実際には限定されていません。 – Fionn

+0

'ネストセット'モデルは、SQLでサブツリーを非常に高速に選択する方法です。 – ChrisW

+0

これはBigtableのようなデータベースシステム上で実行される良い変更です - 単純なテーブルだけの結合はありません。 ネストされたセットが高速であっても、標準のテーブル参照とは異なり、スケーリングがうまくいかないと思います。 – Fionn

0

ポインタを逆にする必要があります。

「ハリー」「サイト2」に「管理者」のアクセス権を持っている「サイト2管理者」のメンバーであるので、彼はこのように「書く」と「その内容を読んで、「削除」することができます。

なぜ」管理"Harry"と "Joe"の間の共通点であるはずです。Harryは1つのサイトの管理者ですが、別のユーザーのユーザーであり、Joeはその逆です。

+0

誰かが読み書きしたり、そのユーザーを含むロールがプロパティに追加されているかどうかに完全に依存するものがあれば、管理者が何かを行うというルールはなく、SomeUsersロールという名前になっている可能性があります。 – Fionn

関連する問題