権限管理ベストプラクティス:四、データレベルクエリー権限管理
4497 ワード
-----------------------------------------------------------------------------------------------------
Ralasafeがオープンしてからしばらく経ち、約2ヶ月になりました.コミュニティのフィードバックによると、私はRalasafeのベストプラクティスをめぐって、一連のBLOGを書くつもりです.
大体の内容は以下の通りです.
1,ログイン制御:どのページがログインしてからアクセスできるか、ログインユーザー名、パスワード検証、ログイン転向ページ;
2,URL権限制御:どのページアクセスがロール権限検証を行う必要があり、どのように検証するのが最も簡単で有効で、どのように検証の失敗状況を処理するか;
3、データレベルの権限管理方案の検討:ミドルウェアを選択しますか?それともフレームワークを選択しますか?
4,Ralasafeアーキテクチャ:ユーザーはどのように読み取り、ユーザーはどのようなフィールドを持っていて、どのように応用基礎と;
5,データレベルクエリー権限管理:どのようにして異なる人に異なるクエリーデータ権限を割り当て、where条件を返しますか?それとも結果セットを直接返しますか?
6、データレベルの意思決定権限管理:どのように異なる人に異なるデータ操作権限を割り当て、ユーザーが権限を備えていない場合はどうすればいいですか?
7、その他の細かい権限制御:ドロップダウンボックスに内容を表示する;ボタン、リンクが表示されているかどうか、画像が表示されているかどうかなど.
-------------------------------------------- ------- --------------------------------
データ・レベルの権限管理要件
データレベルの権限管理の要件は主に次のとおりです.
1、異なるユーザーがデータを照会することをサポートするのは異なる.
2、データベースの行レベル、列レベルのクエリーをサポートする.
3、ページングクエリーをサポートする——2つの方面を含む:a、ページングデータを検出する;b、総データの本数を教えてもらえますか.
4、カスタム条件をサポートする(例えば、張三は自分のクエリー権限の範囲内で、50 w以上の注文をクエリーする).
りろんぶんせき
データレベルの権限をビジネスから分離できることは、長年にわたって開発者が追求してきた目標です.難病に遭遇すると、すぐに難易度の高いAPIプログラミングや、きらびやかなXML構成を連想させます.
しかし、私の今日の分析は、極めて簡単です.しかし、私は皆さんに見てもらうことを強くお勧めします.この案に疑問がある場合は、あなたの応用例を使用して試験してください.私が確認できなかったとき、そうしました.
(当初、私がこの案を提案したとき、私たちのチームはこの案があまりにも簡単で、実行できないと思っていました.私は彼らにこの案を実現させることを堅持しました.製品ができた後、彼らは少し悟って、この案が実行できると思っていました.私が彼らにdemoをさせたとき、この案をケースに運んだとき、彼らは足をたたいて「素晴らしい!あなたも感じてほしい」と言いました)
分類思想の提出
まず、私たちはこの問題を考えます.なぜ私たちはプログラムの中でif/elseを使ったのですか.なぜデータ・レベルの権限が処理しにくいのですか?
原因は:1、多くの情況があります;2,異なる人,異なる状況に対して異なる権限論理を行う必要がある.例:
if ？ then ；
else if ？ then （${ }） ；
else //
then （${ }）RBACモデルにはユーザグループの概念があり,データレベルの権限管理分野にユーザグループを導入する開発者も少なくない.グループはユーザをグループ化するのに適しているが,事前にユーザをグループ化することが不十分である.例えば、張三を「本社ユーザーグループ」に指定する前に、彼はそのユーザーグループに属していない.張三の機構属性が本社に属していることを示しても.
グループを少し改造します.ルールを使用してグループを定義し、ルールを満たすユーザーは、そのユーザーがグループに属していると考えます.従来のプログラミングにおけるif/else判断条件は,基本的に規則や規則式グループを用いて記述できる.この時、張三の機構属性は本社であることを示し、彼は本社のユーザーグループに属している.もし彼の機関属性が支社であれば、彼は支社のユーザーグループに属します.追加の操作は必要ありません(指定、再割り当てなど、すべてがダイナミックインテリジェントです).
OK,そこで,ルール記述を用いた「ユーザ分類」を提案した.このルールは,ユーザ情報,コンテキスト情報,データクエリなどを読み出し,関連演算(比較,集合演算など)を行うことができるはずである.
これにより、ユーザーの分類に基づいて、ユーザーの分類ごとにクエリーを割り当てることができます.(クエリは、ユーザパラメータ、コンテキストパラメータなどの関連パラメータを受け入れることができます)
上記の例では、分類思想を用いて、このように解決することができます.
ユーザー分類:本社ユーザークラス-クエリー:すべての注文を問い合わせる
ユーザー分類:支社ユーザー類——照会:本社及び部下子会社の注文を照会する;
ユーザー分類:子会社ユーザー類——照会:ノート会社の注文を照会する.
機能権限との結合
機能権限とデータ権限を分けるのは適切だと思います.機能権限は企業IT管理者によって維持される.データ権限はソフトウェア開発者が維持します.このケースをどう処理するかなど、これはよくないと言われています.
一般審査員は50 wの財務データを審査することができる.中級審査官は50 w～500 wの財務データを審査する.これは50 w、500 wで、企業は自分でメンテナンスする必要があります.
OK、この50 w、500 wは「権限ポリシーデータ」と呼ぶべきだと思います.データベースに保存したり、基礎データやデータ辞書として企業がインタフェースを通じて自分で維持したりすることができます.ソフトウェア開発者は、開発した「データ・レベルの権限」ポリシーでこれらのデータを読み取ります.(もちろん、キャッシュできます...)
Ralasafeスキーム
データ・レベルのクエリー権限の実装方法
このセクションの内容を理解するには、ralasafe demoアプリケーションをダウンロードし、グラフィックインタフェースと照らし合わせて、より理解しやすいことをお勧めします.
Ralasafeは、管理インタフェースを使用して、ユーザー分類、データ照会をカスタマイズします.カスタマイズに間違いがないことを確認するために、Ralasafeはオンラインテストをサポートします.たとえば、ユーザー分類をカスタマイズした後、テストのためにユーザーを選択できます.データ照会などはオンラインでテストできます.
カスタマイズが完了したら、ユーザー分類とデータクエリーをペアにし、特徴権限を付与します.1つの権限で、複数の(ユーザー分類-データクエリー)ペアを割り当てることができます.前の理論分析と同じです.
具体的にカスタマイズして、どのようにペアリングして、ドキュメントを参考にすることができて、ピクチャーを添えて、ここで多く言わないでください.ユーザー分類をカスタマイズし、データ・クエリーをカスタマイズし、権限付与ポリシー(ペアリング)を与えます.
アプリケーションとどのように結合するか
Ralasafe提供org.ralasafe.Ralasafeとorg.ralasafe.WebRalasafeの2つのインタフェースクラス.内のqueryメソッドは、データ・レベルのクエリー権限に対応します.アプリケーションシステムに対応する場所で、このメソッドを呼び出せばよい.システムの制御層で呼び出すことをお勧めします.すなわち、servletまたはactionです.
ralasafe demoの例では、EmployeServiceletはこのように呼び出されます.(demoは従業員クエリーを示し、受注クエリーではありません)
// Ralasafe
Collection employees = WebRalasafe.query(req, Privilege.QUERY_EMPLOYEE);
// request，
req.setAttribute("employees", employees);OK、簡単です.プログラミングが必要な作業量は非常に少なく、究極に達しています.世界はこれから清らかになった.
(WebRalasafe.queryメソッドはreqパラメータを受け入れ、ここからUserを読み込む.Ralasafe.queryメソッドは直接Userに転送され、非webクラスアプリケーションで呼び出すことができる)
システム構造
Ralasafeは、権限エンジンと管理インタフェースから構成されています.権限エンジン解析権限ポリシー;管理インタフェース生成、メンテナンス権限ポリシー.図のように:
注意:ralasafeチームブログはjavaeye/baidu/blogjavaなどのスペースで、同期して公開されています.ralasafe公式サイト:http://www.ralasafe.org/zh