Question

Lets say I have an ASP.Net MVC App and this app (UI) references a Business Logic Layer (BLL) and the BLL references my Data Access Layer (DAL).

I am utilizing a Custom Membership and Role provider for Authorization.

I am trying to determine what layers need to reference my Membership provider.

In MVC you can perform Authorization checks in the following manner:

[Authorize(Roles = "SomeRoleName")]
public ActionResult Index()
{
//do something
}

And in my BLL I may want to check to see if a User is in a Role as well:

public static bool IsRoleEditor(User user, Role userRole)
  {
   bool retValue = false;

   if (user.Application.AppID == UserRole.Application.AppID)
   {
        if (Roles.IsUserInRole("ModifyRoles"))
        {
           retValue = true;
        }


    return retValue;
   }

I would have to reference and instantiate the Membership classes in both layers if I do this. Is this the correct way to architect an app like this? Seems like a lot of redundancy.

Since I have a BLL do I avoid using the “[Authorize(Roles = “SomeRoleName”)]” attributes and instead call a BLL function from within the MVC code to check if the user is in a role? If I do this the MVC still needs a reference to the membership provider for authentication and such anyway to take advantage of the Login and other ASP controls, right?

Am I way off base and heading in the wrong direction?

Answer 1

In my view this is a weakness of the Membership/Role design.

The way I would get round this, for example to have role-based authorization on both UI and BLL tiers in a distributed n-tier app, would be to expose a service in the BLL tier that exposes the relevant bits (GetRolesForUser etc) and is implemented by calling the RoleProvider on the server.

Then implement a custom RoleProvider on the client that is implemented by calling the service exposed by the BLL.

In this way the UI tier and BLL tier both share the same RoleProvider. The UI tier can use knowledge of the current user’s roles to improve the UI (e.g. hiding/disabling UI controls corresponding to unauthorized features), and the BLL can ensure that users can not execute
business logic for which they are not authorized.