Home/ Questions/Q 6383889
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T02:42:23+00:00

I need a gear for custom authorization in business logic classes. It has to

  • 0

I need a gear for custom authorization in business logic classes. It has to be permissions based system, but I can not decide how to apply authorization rules to methods.

My first thought was to apply custom attributes to method

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

My business logic class has interface, so I can use, for example, Unity Interception behavior and check in runtime if current user has required permissions. And throw an exception if he has not.

But now I’m concerned about reliability of this method.

Usually the reference to business logic class injected by unity container. So there is no problem because it is configured to apply interface interception mechanism.

But what if some developer will instantiate my business logic class directly? Then no interception will be applied and he will be able to call any method even if current user has not permissions to make some actions or even he is not authenticated.

Also somebody can change unity container configuration, turn off Interception extension completly. Again my authorization system will not work.

I saw ASP .NET MVC is using similar mechanism for authorization. Authorization rule is applied only when request came by standard way (IController.Execute). I think this is not a problem in this case because end user of controller (web user) has no way to access controller class directly.

In my case end user of business logic is a programmer who develops front end and he can intentionally or unintentionally screw things – create instance of business logic class and call any methods.

What can you suggest me? How do you deal with this kind of problems?

Thank you.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The .NET Framework supports a mechanism for declarative permission verifications that does not depend on Unity interception or other “external” AOP. In order to take advantage of this, your attribute must inherit from System.Security.Permissions.CodeAccessSecurityAttribute. The System.Security.Permissions.PrincipalPermissionAttribute that is included in the BCL is an example of using this mechanism to evaluate user permissions. If it does not suit your needs, there’s nothing stopping you from creating your own attribute that does.

    • 0