This article describes an easy, manageable and light way to secure methods in your application.
Lately, I have been developing an application, some parts (methods) of which needed to be secured and available only for some users. The requirement was also that the model should be very flexible and portable so it can be used in stand-alone and Web applications.
After some searching, I have found two solutions that have partially been solving my problem.
.NET Framework offers the PrincipalPermission class that can solve this problem:
public class MyClass
{
[PrincipalPermission(SecurityAction.Demand, Name = “Comp1\Administrator”)]
public void MyMethod()
{
}
}
When a user that is not an Administrator will try to access this method, an exception will be thrown. Attributes itself are not called before every method by default. They are called during reflection of a given assembly and this is done here by the .NET Framework.
This works fine but there are some limitations:
This brings us to the second solution. You can also do it in a basic manner by imperatively calling a security check inside a method:
public class MyClass
{
public void MyMethod()
{
if(!IsPermited(MethodInfo.GetCurrentMethod(), User))
{
throw new NotAuthorizedException();
}
}
}
IsPermited can take authorization values written inside a database and authorize the user to use (or not) this MyMethod. The table with security values can look like this:
| Id | Method_Name | User_Id |
| 1 | MyClass.MyMethod |
1 |
The problem with this solution is that it is very hard to manage since the names of the secured parts of your application are not strongly-typed. For example, if you want to add permission for a new user, you have to put “by hand” name of your secured method. Those values can be kept inside another DB table or in the configuration file, but it can still create desynchronization with data in your application so it is a potential source of errors.
The third solution was to combine the above two solutions and create a “Hybrid”.
We will leave imperative call of the security method but the class and method in which it is called must be “signed” by our specific attribute. That attribute checked during the call of the IsPermited method and if the call comes from “not signed” method, an exception is raised.
So now MyMethod should look like this:
public class MyClass
{
[MethodSecured]
public void MyMethod()
{
if(!IsPermited(MethodInfo.GetCurrentMethod(), User))
{
throw new NotAuthorizedException();
}
}
}
Ok. So what about managing the permissions? This is now the easiest part. What we have to do is to scan the assembly using reflection and search for methods that are marked with the MethodSecured attribute.
Then it is just a matter of assigning methods to a specific user and putting it into the database.
The solution contains three projects:
SecuredLibrary – Contains basic engine of Security Model and Presenters to it. SecuredLibraryTest – Contains test for SecuredLibrary. This is the best place to see how to use SecuredLibrary assembly. SecurityManagementConsoleApplication – basic console application that is only GUI (View) to presenter DisplayAllObjectsToSecurePresenter located in SecuredLibrary. The Presenter uses reflection to scan assembly SecuredLibrary.dll in search for methods marked with MethodSecuredAttribute. SecuredLibrary project and see how everything is working on the inside (or better still, debug it). Display that application console. It is built on a classic MVP (or rather VP since in this example I do not use Model to access the database). My solution isn't probably the best that exists, but for me it worked great since it can be totally independent from any build in security mechanisms and as a result, can be moved very easily.
| You must Sign In to use this message board. | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
