2009-08-24 3 views
0

実行時に作成されるオブジェクトに対するロールベースの認可にAzManを使用できますか?はいの場合、どうすればこのことができますか?例については実行時に作成されるオブジェクトに対するロールベースの認可にAzManを使用できますか?

クラス「CustomAlert」のオブジェクトは、実行時に作成された場合、私はクラスの異なるオブジェクト「CustomAlert」のために異なるルールを持つことができるかどうかを確認しようとしています。特定のユーザーのIDを使用してオブジェクトを作成すると、そのユーザーがそのオブジェクトのCREATOR/OWNERであると考えるユーザーには、より多くの権限が与えられます。作成者/所有者のみがオブジェクトを変更できます。

答えて

0

Azmanはロールベースのセキュリティをサポートしていますが、ACLのみではなく、ロールのみに基づいています。特定のユーザーがログインしている場合は、そのユーザーに基づいて特定のアクセス許可が与えられますが、これらのアクセス許可は静的な値に過ぎません。特定の種類のすべてのオブジェクトに適用されますが、そのタイプのインスタンス。

4

確かにAzManを使用することは可能です。私はこの形式のリソースと役割ベースのセキュリティでいくつかのアプリケーションを実装しました。 AzManは実際には非常に柔軟性があります。また、カスタム・ユーザーとグループ、階層全体の役割の完全継承、あらゆるレベルの操作を拒否する能力など、リソース階層(Windowsファイル・システム・セキュリティと考える)も実装しました。これを行うには、AzMan Scopesを理解する必要があります。

AzManスコープを使用すると、特定のリソースの個別の役割/操作セットを作成できます。このリソースは、あなたが選んだものであれば何でもかまいません。AzManの文字列識別子です。これらのロール/操作は、アプリケーションレベルで割り当てられたロールに追加されます。

以前に実装した方法は、オブジェクトのIDをスコープ名として使用することです。理想的には、これはGUID(理想的にはMMCアプリケーションが非常に乱雑になりますが)でなければなりませんが、同様に「タイプID」の形式、つまり「CustomerAlert-1」(MMCアプリでは友好的です)を使用できます。 azmanでAccessCheckを実行するときは、スコープ名をAccessCheckに渡します(AccessCheckの定義で配列が許可されていても、スコープは1つだけです)。

私は(誰が苦労のために)これを行う方法の一例を通じて実行されます...

  1. は、 CustomerAlertView、 CustomerAlertEdit、 アプリケーションレベルで CustomerAlertDeleteなどの操作を作成します。
  2. アプリケーションレベルで という定義をCustomerAlertOwner という名前で作成します。
  3. 操作をCustomerOwner ロールに追加します。
  4. アプリでは、「CustomerAlert-1」というスコープ を作成します。
  5. スコープの に "Owner"という役割の割り当てを作成します。
  6. 「Owner」ロール の割り当てにCustomerAlertOwner ロール定義を追加します。
  7. このオーナーロールには、顧客/ユーザー「Dave」 を追加します。
  8. あなたが DeleteCustomerAlert()と言うにアクセスチェックを行う 、あなたは、単に CustomerAlertDelete操作のIDを渡し今
  9. と タイプ/あなたが すなわちスコープ」として削除したい オブジェクトのid CustomerAlert-1 "

オブジェクトプロパティベースのアクセスチェック(つまり、特定のプロパティの読み取り/書き込みをロックアウトする)の場合、私は考えることができる2つのアプローチがあります。プロパティとアクセスタイプ、つまりPropertyNameGet、PropertyNameSet、PropertyAddressAdd。アプリケーションレベルで操作を作成し、タスク/役割を使用して一般的に使用されている権限セットをグループ化することで、これを単純化できます。もう1つの方法は、各プロパティ(CustomerAlert-1-Name)のスコープを使用することですが、これは面倒で効率的ではありません。特定のオブジェクトにアクセスする際に複数のスコープを個別にロードする必要があります。

AzManでは操作を明示的に拒否できないことに注意してください。アプリケーション/スコープ内でユーザーの役割を割り当てないでください。これは、特定のタイプのリソース階層(グループ/ユーザー)などが実装することがより困難になる可能性があることを意味します。

さらに詳しい情報が必要な場合は、お気軽に質問してください。私はほとんどのシナリオについて説明しました。

関連する問題