3

ビジネスロジッククラスでのカスタム認証用のギアが必要です。権限ベースのシステムである必要がありますが、承認ルールをメソッドに適用する方法を決定できません。

私の最初の考えは、カスタム属性をメソッドに適用することでした

[NeedPermission("Users", PermissionLevel.Read)]
public IList<User> GetAllUsers()
{
     // some code goes here
}

私のビジネスロジッククラスにはインターフェイスがあるので、たとえばUnity Interceptionの動作を使用して、現在のユーザーに必要なアクセス許可があるかどうかを実行時にチェックできます。そして、そうでない場合は例外をスローします。

しかし今、私はこの方法の信頼性について心配しています。

通常、Unityコンテナによって注入されるビジネスロジッククラスへの参照。したがって、インターフェース傍受メカニズムを適用するように構成されているため、問題はありません。

しかし、開発者が私のビジネスロジッククラスを直接インスタンス化するとしたらどうでしょうか。その後、インターセプトは適用されず、現在のユーザーが何らかのアクションを実行する権限を持っていない場合や、認証されていない場合でも、メソッドを呼び出すことができます。

また、誰かがユニティコンテナの構成を変更し、Interception拡張機能を完全にオフにすることができます。繰り返しますが、私の認証システムは機能しません。


ASP.NETMVCが承認に同様のメカニズムを使用しているのを見ました。承認ルールは、要求が標準的な方法(IController.Execute)で送信された場合にのみ適用されます。この場合、コントローラーのエンドユーザー(Webユーザー)にはコントローラークラスに直接アクセスする方法がないため、これは問題ではないと思います。

私の場合、ビジネスロジックのエンドユーザーはフロントエンドを開発するプログラマーであり、意図的または意図せずに物事をねじ込むことができます。ビジネスロジッククラスのインスタンスを作成し、任意のメソッドを呼び出すことができます。

何を提案できますか?この種の問題にどのように対処しますか?

ありがとうございました。

4

2 に答える 2

1

.NET Frameworkは、Unityインターセプトやその他の「外部」AOPに依存しない宣言型パーミッション検証のメカニズムをサポートしています。これを利用するには、属性がSystem.Security.Permissions.CodeAccessSecurityAttributeから継承されている必要があります。BCLに含まれているSystem.Security.Permissions.PrincipalPermissionAttributeは、このメカニズムを使用してユーザー権限を評価する例です。それがあなたのニーズに合わない場合、あなたがそうするあなた自身の属性を作成することを妨げるものは何もありません。

于 2011-09-01T12:17:23.707 に答える
1

コンストラクターが内部にあり、オブジェクトがファクトリからインスタンス化されている場合、開発者はエラーによってセキュリティをバイパスできません。

誰かが本当に本当にセキュリティなしでオブジェクトを作成したい場合でも、リフレクションを使用して作成できますが、これはかなり意図的に行う必要があります。

于 2011-09-01T13:43:22.030 に答える