Exam 70-486 Objective 3.3 Design and implement MVC controllers and actions: Apply authorization attributes

Attributes are based on the System.Web.Mvc.FilterAttribute class.

Their primary purpose is to analyse information coming into the controller, especially HttpContext, and determine if it meets certain criteria

=> basically perform some logic before and/or after an action method is executed.

MVC Framework support five different types of filters:

The ActionFilterAttribute class implements both the IActionFilter and IResultFilter interfaces.

·         This class is abstract, which forces you to provide an implementation.

The AuthorizeAttribute and HandleErrorAttribute classes contain useful features and can be used without creating a derived class.

In order for a .Net class to be treated as an MVC filter, it must implement IMvcFilter – you can do this directly or derive from FilterAttribute class.

To implement a custom Authorization Filter

Derive from AuthorizeAttribute and override the AuthorizeCore method:

    public class AuthorizeFilterAttribute : AuthorizeAttribute

    {

        protected override bool AuthorizeCore(HttpContextBase httpContext)

        {

            // Logic here

            return true;

        }

    }

Some devs will implement IAuthorizationFilter themselves in order to gain access to the AuthorizationContext (contains more info like routing data and which controller/action is being called).

This is not recommended because:

• Best not to include controller/action specific logic in the Authorization filter
• Doing so breaks the seperation of concerns and causes testing problems
• Keep it simple; let the context of what is being authorized come from where the attribute is applied.
• Put global authorization concerns in the Authorization filter; e.g. a request from a certain domain should always be denied
• Keep the security checks as close as possible to the resource being secured -> this way no matter how the user got to the resource, there will always be a security check.

Using the built-in Authorization Filter

Can provide an authorization policy by specifying two public properties: Users and Roles

[Authorize(Users = "admin, spoc", Roles = "Manager, DeckHand")]

    public class AccountController : Controller

This will authorize users admin and spoc to access the Account controller, as long as they are in at least one of the Roles Manager or DeckHand.

Note that there is an implicit restriction here that the above users must be authenticated.

=> if no Users or Roles are specified, then any User, in any Role can access the controller.

If the filter denies the request, the MVC framework will return a 401 Not Authorized response, which is then internally converted to a 302 redirect to the login page and the browser will respond to this by prompting the user for credentials.

The 401 to 302 conversion is handled by Open Web Interface for .Net (OWIN) components.

In previous versions; this redirect was handled by defining a loginUrl in the <authentication> element of web.config.

SECURITY WARNING: If you ever attempt to write your own Account controller, be aware of the risk of Open Redirection Attacks that arise due to the 401 to 302 redirection process.