Monday, April 5, 2010

Securing Controller Actions in ASP.NET MVC for Multi-Tenant Applications

One of the cool things about using the MVC Framework is that you get clean RESTful urls e.g.

/Product/Edit/1

This is all well and good but when developing a multi-tenant application which uses a Shared datastore it is extremely important that your controller actions are secure in the sense that the Urls can’t be tampered with.

Believe it or not but this level of security is often neglected in a lot of projects or is at the least an afterthought.

You could implement in every controller action something like below:

        public ActionResult Edit(int id)
        {
            if (!catalogService.HasAccessToProduct(UserContext.UserId, id))
            {
                HttpContext.Response.Status = "401 Unauthorized";
                HttpContext.Response.StatusCode = 401;
                Response.End();
            }

            var product = catalogService.GetProductById(id);

            ViewData.Model = product; 

            return View();
        }

However this is very repetitive, likely to be forgotten and prone to logic errors.

With the flexibility of the MVC Framework you have the ability to create your own Action Filters. Here is an example of an Action Filter that inherits from the Authorize Attribute.

public class ProductAuthorizeAttribute : AuthorizeAttribute
   {
       private string routeDataKey = "id";

       public string RouteDataKey
       {
           get { return routeDataKey; }
           set { routeDataKey = value; }
       }

       public override void OnAuthorization(AuthorizationContext filterContext)
       {
           var userContext = UserIdentity.GetCurrent() as IUserContext;
           var productId = 0;

           if (!filterContext.RouteData.Values.ContainsKey(RouteDataKey))
           {
               throw new ApplicationException("RouteDataKey " + RouteDataKey +
                                              " does not exist in the current RouteData");
           }

           int.TryParse(filterContext.RouteData.Values[RouteDataKey].ToString(), out productId);

           if (productId > 0)
           {
               CheckAccess(productId, filterContext, userContext);
           }
       }

       private static void CheckAccess(int productId, 
           AuthorizationContext context, 
           IUserContext userContext)
       {
           var entityPermissionService = ServiceLocator.Resolve<IEntityPermissionService>();

           var hasAccess = entityPermissionService.HasAccessToProduct(userContext.UserId, productId);

           if (hasAccess) return;

           context.HttpContext.Response.Status = "401 Unauthorized";
           context.HttpContext.Response.StatusCode = 401;
           context.HttpContext.Response.End();
       }
   }

 

Then your Controller action looks like this. Much cleaner. 

        [ProductAuthorizeAttribute(RouteDataKey="id")]
        public ActionResult Edit(int id)
        {
            var product = catalogService.GetProductById(id);

            ViewData.Model = product; 

            return View();
        }

The great thing about this approach is that you can implement this at any time without changing any code other than adding the Attribute to the relevant Controller Actions.

Thursday, April 1, 2010

Pre-Generating Views in Entity Framework .NET 4.0

 

UPDATED ON: 16/09/2010

If you’re using Entity Framework chances are you’ve come up against performance issues already, especially when instantiating your Object Context.

One very reliable way to increase performance is to pre-generate the Views. Depending on the size of your model and in my experience it can shave as much as 40% off the instantiation time.

There is a good overview on MSDN, however it only covers .NET 3.5.

Step 1

Go to your Model properties and select “Copy to Output Directory” for the Metadata Artifact Processing option.

ef-pre-generate

The result of this is you will end up with the .ssdl, .csdl and .msl files in your output directory which in this case is bin/Debug.

Step 2


Next you need to setup the Pre-build event to use the EDMGen.exe tool.
NB: If you use the Command on the MSDN site you will come across this error.

“The required parameter ‘mode’ is missing”

The correct command to use is:

"%windir%\Microsoft.NET\Framework\v4.0.30319\EdmGen.exe" /mode:ViewGeneration "/inssdl:$(TargetDir)MyModel.ssdl" "/incsdl:$(TargetDir)MyModel.csdl" "/inmsl:$(TargetDir)MyModel.msl" "/outviews:$(ProjectDir)MyModel.Views.cs" /nologo /language:CSharp

 

Step 3

The .ssdl, .csdl & .msl files will be generated on every build and output to the TargetDir, however it’s a good idea to include them in your Project.

In the Post-build event you can add a simple XCOPY like below to copy the files to the root of your project:

XCOPY "$(TargetDir)MyModel.csdl" "$(ProjectDir)" /R /Y
XCOPY "$(TargetDir)MyModel.ssdl" "$(ProjectDir)" /R /Y
XCOPY "$(TargetDir)MyModel.msl" "$(ProjectDir)" /R /Y

 

Step 4

Build the project which contains your Entity Model.

If it built successfully you should find the following files in the root of your Project folder

  • MyModel.Views.cs
  • MyModel.csdl
  • MyModel.ssdl
  • MyModel.msl

Go ahead and include all these files in your project, Show All Files > Right Click > Include In Project

Step 5

Now for MyModel.csl, MyModel.ssdl, MyModel.msl you want to include these as an embedded resource

For each of the above files select the “Embedded Resource” Build Action in the Properties window.

Step 6

Now it’s time to update your Entity Connection String to use the embedded resources.

Personally I prefer to use fully qualified names for the embedded resources.

e.g.

res://*/MyNamespace.MyModel.MyModel.csdl 
You should end up with a Connection String looking like below. 
<connectionStrings>
    <add name="MyModel_Entities" connectionString="metadata=res://*/MyNamespace.MyModel.MyModel.csdl|res://*/MyNamespace.MyModel.MyModel.ssdl|res://*/MyNamespace.MyModel.MyModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=local;Initial Catalog=MyModelDatabase;Integrated Security=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />
  </connectionStrings>

If the path to the embedded resource is wrong you can expect to get a System.Data.MetadataException

Unable to load the specified metadata resource.

To be sure what the Resource path is, you can always use the trusty Reflector.

Finished

Enjoy your new found Entity Framework performance.
If you have any problems, don’t hesitate to let me know.