ASP.NET

  • Artículo

Filtros de seguridad de la API web de ASP.NET

Badrinarayanan Lakshmiraghavan

La autenticación y autorización son las bases de la seguridad en aplicaciones. La autenticación establece la identidad de un usuario validando las credenciales facilitadas, mientras que la autorización determina si un usuario está autorizado para realizar una acción solicitada. Una API web protegida autentica solicitudes y autoriza el acceso al recurso solicitado en función de la identidad establecida.

Puede implementar autentificación en ASP.NET Web API por medio de los puntos de extensibilidad disponibles en la canalización ASP.NET Web API así como por medio de las opciones proporcionadas por el host. Con la primera versión de ASP.NET Web API, una práctica común consiste en utilizar un filtro de autorización o de acción para implementar la autenticación. ASP.NET Web API 2 presenta un nuevo filtro de autenticación dedicado al proceso. Este nuevo punto de extensibilidad permite separar claramente los conceptos de autenticación y de autorización. En este artículo, voy a presentarle estos dos filtros de seguridad y a mostrarle cómo utilizarlos para implementar la autenticación y la autorización como conceptos separados en ASP.NET Web API.

Opciones para implementar aspectos de seguridad

La autenticación y autorización en ASP.NET Web API pueden implementarse por medio de los puntos de extensibilidad ofrecidos por el host, así como los disponibles en la propia canalización de ASP.NET Web API. Las opciones basadas en host incluyen módulos HTTP y componentes middleware de OWIN, mientras que las opciones de extensibilidad ASP.NET Web API se componen de controladores de mensajes, filtros de acción, filtros de autorización y filtros de autenticación.

Las opciones basadas en host se integran bien en la canalización de host y son capaces de rechazar solicitudes incorrectas de la canalización. Las opciones de extensibilidad de ASP.NET Web API, por otro lado, proporcionan un nivel de control más preciso sobre el proceso de autenticación. Es decir, podrá configurar distintos mecanismos de autenticación para diferentes controladores e incluso, distintos métodos de actuación. La compensación es una mejor integración con el host y un rechazo temprano de solicitudes incorrectas frente a la granularidad de autenticación. Aparte de estas características generales, cada opción tiene sus propios pros y contras, como abordará en los apartados siguientes.

Módulo HTTP Esta es una opción para API web que se ejecutan en IIS. Los módulos HTTP permiten que el código de seguridad se ejecute antes como parte de la canalización IIS. La entidad de seguridad establecida desde un módulo HTTP está disponible para todos los componentes, incluidos los componentes IIS que se ejecutarán más adelante en la canalización. Por ejemplo, cuando la entidad de seguridad se establece por un módulo HTTP en respuesta al evento AutenticateRequest, el nombre de usuario de la entidad de seguridad se registra correctamente en el campo cs-username de los registros IIS. El inconveniente principal de los módulos HTTP es la falta de granularidad. Los módulos HTTP se ejecutan en todas las solicitudes que se realizan a la aplicación. Para una aplicación web con distintas capacidades como generación de revisión HTML, API Web y demás, tener un módulo HTTP que exija la autenticación de un modo no suele ser un enfoque suficientemente flexible. Otro inconveniente de utilizar un módulo HTTP es la dependencia del host—IIS, en este caso.

OWIN Middleware Esta es otra opción de host relacionada, disponible con hosts OWIN. ASP.NET Web API 2 es totalmente compatible con OWIN. Puede que una de las razones más atractivas para utilizar OWIN middleware para la seguridad sea que ese mismo middleware puede ejecutarse en distintos marcos de trabajo. Esto significa que puede utilizar múltiples marcos de trabajo como ASP.NET Web API, SignalR, etc. en su aplicación y seguir utilizando un middleware de seguridad común. Sin embargo, la mínima granularidad de OWIN middleware podría constituir una limitación, ya que OWIN middleware se ejecuta en la canalización OWIN y suele invocarse para todas las solicitudes. Asimismo, OWIN middleware solo puede utilizarse con hosts compatibles con OWIN, si bien esta dependencia es comparativamente mejor que otras con un servidor/host específico como IIS, como sucede con los módulos HTTP. Otro aspecto importante es que OWIN middleware puede ejecutarse en la canalización ASP.NET (integrada en IIS) gracias al paquete Microsoft.Owin.Host.SystemWeb.

Controlador de mensajes Una opción de extensibilidad proporcionada por ASP.NET Web API, lo mejor de utilizar un controlador de mensajes para la seguridad es un concepto del marco de trabajo de ASP.NET Web API y, en consecuencia, no depende del servidor o host subyacente. Asimismo, un controlador de mensajes solo se ejecuta en solicitudes de API web. El inconveniente de utilizar un controlador de mensajes es la falta de control más preciso. Un controlador de mensajes puede configurarse para ejecutarse como un controlador global para todas las solicitudes o para una ruta concreta. Para una ruta en particular, puede tener múltiples controladores. Todos estos controladores y el método de acción que contienen deben compartir la misma autenticación exigida por el controlador de mensajes y configurada para dicha ruta. En otras palabras, la menor granularidad de autenticación implementada por un controlador de mensajes se encuentra en el nivel de ruta.

Filtro de acción Otra opción de extensibilidad proporcionada por ASP.NET Web API es el filtro de acción. Sin embargo, desde la perspectiva de implementar autenticación, no se trata de una opción viable porque se ejecuta después de que se ejecuten los filtros de autorización en la canalización ASP.NET Web API. Para que la autenticación y la autorización funcionen correctamente, la autenticación debe preceder a la autorización.

Filtro de autorización Otra opción de extensibilidad proporcionada por ASP.NET Web API es el filtro de autorización. Una de las formas más comunes de implementar la autenticación personalizada para escenarios que exijan más granularidad de la que los controladores de mensajes pueden ofrecer consiste en utilizar un filtro de autorización. El problema principal de utilizar un filtro de autorización para la autenticación y la autorización es que el orden de ejecución de los filtros de autorización no está garantizado por una ASP.NET Web API. Esto significa que el filtro de autorización que realiza la autorización podría ejecutarse muy bien antes de que se pudiera ejecutar su filtro de autorización realizando la autenticación, convirtiendo así la opción del filtro de autorización igual de inapropiada para autenticación que la opción del filtro de acción.

Filtro de autenticación El punto principal de este articulo es la nueva opción de extensibilidad disponible con ASP.NET Web API 2. Los filtros de autenticación se ejecutan después de los controladores de mensajes pero antes del resto de tipos de filtros. Por tanto, son la mejor opción para implementar cuestiones de autenticación. Lo más importante es que los filtros de autenticación se ejecutan antes que los filtros de autorización. Al utilizar un filtro dirigido específicamente a la autenticación o a la autorización, puede separar las cuestiones de autenticación y de autorización.

Además, los filtros de autenticación ofrecen un nivel de control o de granularidad que los hace especialmente útiles. Veamos el ejemplo de una API web diseñada para ser consumida por aplicaciones móviles nativas y aplicaciones AJAX basadas en explorador. La aplicación móvil puede presentar un token en el encabezado de la autorización HTTP mientras que la aplicación AJAX puede utilizar una cookie de autenticación como credencial. Además, supongamos que un subconjunto de la API es sensible y está disponible únicamente para la aplicación móvil y usted quiere asegurarse de que solo se accede a los métodos de acción presentando un token y no una cookie (las cookies son susceptibles de falsificación de solicitud entre sitios [XSRF], mientras que un token en un encabezado de autorización HTTP no lo es). En este caso, la autenticación debe realizarse con un nivel más preciso de granularidad de lo que es posible con una opción basada en host o incluso con un controlador de mensajes. Un filtro de autenticación encaja perfectamente en esta situación. Puede aplicar el filtro de autenticación basado en el token en todos aquellos controladores o métodos de acción en los que deben utilizarse y el filtro de autenticación basado en la cookie en otros lugares. Suponga, en este escenario, que tiene unos cuantos métodos de actuación comunes y que quiere que sean accesibles a través de un token o de una cookie. Solo tiene que aplicar los filtros de autenticación de la cookie y del token a dichos métodos de acción comunes y uno de los filtros será capaz de realizar las autenticaciones correctamente. Este tipo de control es el mayor valor que aportan los filtros de autenticación a la tabla. Cuando es necesario un control de autenticación granular, el enfoque correcto consiste en implementar las cuestiones de autenticación por medio de un filtro de autenticación y las de autorización por medio de un filtro de autorización.

Merece la pena mencionar que el filtro de autenticación no incluido, HostAuthenticationFilter, habilita la autenticación ASP.NET Web API por medio de OWIN middleware. Mientras el middleware de autenticación OWIN se ejecuta en una canalización e intenta autenticar "activamente" las solicitudes entrantes, también puede configurarse para autenticar la solicitud "pasivamente", solo cuando se solicite. El HostAuthenticationFilter permite ejecutar posteriormente el middleware de autenticación OWIN pasivo por nombre en la canalización de la API web. Este enfoque habilita un código de autenticación que se puede compartir entre marcos de trabajo (incluido el middleware de autenticación OWIN proporcionado por Microsoft) mientras se sigue permitiendo la granularidad por acción para su autenticación.

Si bien puede mezclar la autenticación de nivel host con autenticación más granular basada en en la canalización de API web, tiene que tener muy en cuenta cómo la autenticación de nivel host puede afectar a la autenticación de API web. Por ejemplo, podría tener un middleware de autenticación basado en cookies a nivel de host para utilizarse con otros marcos de trabajo, digamos ASP.NET MEV, pero dejando que la API web utilice la entidad de seguridad basada en cookies la hace susceptible a ataques como XSRF. Para ayudar en dichas situaciones, el método de extensión SuppressDefaultHostAuthentication permite a la API web ignorar toda autenticación configurada a nivel de host. La plantilla predeterminada de Web API Visual Studio tiene cookies habilitadas a nivel de host y utiliza tokens portadores en el nivel de API web. Puesto que las cookies están habilitadas a nivel de host y necesitan mitigación XSRF, la plantilla también utiliza SuppressDefaultHostAuthentication para evitar que la canalización de API web utilice la entidad de seguridad basada en cookies. De este modo, la API web solo utilizará la entidad de seguridad basada en tokens y no tendrá que crear mecanismos para que la API web se defienda de ataques XSRF.

Creación simultánea de filtros de autenticación y de autorización

En la canalización ASP.NET Web API, los filtros de autenticación se ejecutan en primer lugar (seguidos de los filtros de autorización) por la sencilla razón de que la autorización depende de la identidad establecida, que es el resultado de la autenticación. A continuación le muestro cómo diseñar los filtros de autenticación y de autorización para que funcionen conjuntamente para asegurar ASP.NET Web API.

El principio básico de este diseño consiste en conceder al filtro de autenticación la única responsabilidad de validar la credencial y que no tenga que ocuparse de otras cuestiones. Por ejemplo, el filtro de autenticación no rechazará una solicitud con un código de estado 401 no autorizado si las credenciales no están presentes. Simplemente no establece una identidad autenticada y deja en el aire la cuestión de cómo administrar las solicitudes anónimas a la fase de autorización. Un filtro de autenticación se limita a realizar tres tipos de acciones:

  1. Si la credencial de interés no está presente en la solicitud, el filtro no hace nada.
  2. Si las credenciales están presentes y son válidas, el filtro establece una identidad en forma de una entidad de seguridad autenticada.
  3. Si las credenciales están presentes pero son incorrectas, el filtro notifica al marco de trabajo ASP.NET Web API por medio de un resultado de error, que supone una respuesta "no autorizada" que se devuelve al solicitante.

Si ninguno de los filtros de autenticación ejecutados en la canalización pueden detectar una credencial no válida, la canalización sigue funcionando, a pesar de que no se haya establecido una identidad autenticada. Los componentes que se ejecuten más tarde en la canalización serán los que decidirán cómo tratar esta solicitud anónima.

En el nivel más básico, un filtro de autorización simplemente comprueba si la identidad establecida es una identidad autenticada. Sin embargo, un filtro de autorización también puede garantizar que:

  • El nombre de usuario de la identidad autenticada está en la lista de los usuarios permitidos.
  • Como mínimo uno de los roles asociados a la identidad autenticada está en la lista de roles permitidos.

Mientras el filtro de autorización no incluido solo ejecuta el control de acceso basado en rol como acabamos de describir, un filtro de autorización personalizado derivado del filtro de autorización no incluido puede ejecutar un control de acceso basado en reclamaciones comprobando que dichas reclamaciones forman parte de la identidad establecida por el filtro de autenticación.

Si todos los filtros de autorización están contentos, la canalización sigue ejecutándose y, en algún momento, el método de actuación del controlador de la API generará una respuesta para la solicitud. Si la identidad no está establecida o si hay una inconsistencia en términos del nombre de usuario o de los requisitos de rol, el filtro de autorización rechazará la solicitud con una respuesta 401 no autorizada. En la Figura 1 se ilustra el papel desempeñado por los dos filtros en tres escenarios: credenciales no presentes, credenciales incorrectas presentes y credenciales correctas presentes.

Filtros de seguridad en la canalización ASP.NET Web API
Figura 1 Filtros de seguridad en la canalización ASP.NET Web API

Creación de un filtro de autenticación

Un filtro de autenticación es una clase de implementación de la interfaz de IAuthenticationFilter. Esta interfaz cuenta con dos métodos: AuthenticateAsync y ChallengeAsync, tal y como se muestra a continuación:

public interface IAuthenticationFilter : IFilter
{
  Task AuthenticateAsync(HttpAuthenticationContext context, 
    CancellationToken cancellationToken);
  Task ChallengeAsync(HttpAuthenticationChallengeContext context,
    CancellationToken cancellationToken);
}

El método AuthenticateAsync acepta HttpAuthentication­Context como argumento. Este contexto responde a cómo el método AuthenticateAsync comunica el resultado del proceso de autenticación al marco de trabajo de ASP.NET Web API. Si el mensaje solicitado contiene credenciales auténticas, la propiedad de la entidad de seguridad del objeto HttpAuthenticationContext pasado se establece en la entidad de seguridad autenticada. Si las credenciales no son válidas, la propiedad ErrorResult del parámetro HttpAuthenticationContext se establece en UnauthorizedResult. Si el mensaje de solicitud no contiene ningún tipo de credencial, el método AuthenticateAsync no realizará ninguna acción. El código de la Figura 2 muestra una implementación típica del método AuthenticateAsync abordando estos tres escenarios. La entidad de seguridad autenticada utilizada en este ejemplo es una ClaimsPrincipal únicamente con reclamaciones de nombre y rol.

Figura 2 Método AuthenticateAsync

public Task AuthenticateAsync(HttpAuthenticationContext context,
  CancellationToken cancellationToken)
{
  var req = context.Request;
  // Get credential from the Authorization header 
  //(if present) and authenticate
  if (req.Headers.Authorization != null &&
    "somescheme".Equals(req.Headers.Authorization.Scheme,
      StringComparison.OrdinalIgnoreCase))
  {
    var creds = req.Headers.Authorization.Parameter;
    if(creds == "opensesame") // Replace with a real check
    {
      var claims = new List<Claim>()
      {
        new Claim(ClaimTypes.Name, "badri"),
        new Claim(ClaimTypes.Role, "admin")
      };
      var id = new ClaimsIdentity(claims, "Token");
      var principal = new ClaimsPrincipal(new[] { id });
      // The request message contains valid credential
      context.Principal = principal;
    }
    else
    {
      // The request message contains invalid credential
      context.ErrorResult = new UnauthorizedResult(
        new AuthenticationHeaderValue[0], context.Request);
    }
  }
  return Task.FromResult(0);
}

Utilice el método AuthenticateAsync para implementar la lógica de autenticación central de validación de credenciales en la solicitud, y el método ChallengeAsync para agregar el desafío de autenticación. Se agrega un desafío de autenticación a una respuesta cuando el código de estado es 401 no autorizado y para inspeccionar el código de estado necesita el objeto de respuesta. Pero el método ChallengeAsync no le permite inspeccionar la respuesta o establecer el desafío directamente. De hecho, este método se ejecuta antes que el método de acción, en la parte de procesamiento de solicitudes de la canalización de API web. Sin embargo, el parámetro HttpAuthenticationChallengeContext del método ChallengeAsync permite asignar un objeto de resultado de acción (IHttpActionResult) a la propiedad Resultado. El método ExecuteAsync del objeto resultado de actuación aguarda a la tarea que produce la respuesta, inspecciona el código de estado de la respuesta y agrega el encabezado de respuesta WWW-Authenticate. El código de la Figura 3 muestra una implementación típica del método ChallengeAsync. En este ejemplo, solo agrego un desafío codificado de forma rígida. La clase ResultWithChallenge es la clase de resultado de acción que he creado para agregar el desafío.

Figura 3 Método ChallengeAsync

public Task ChallengeAsync(HttpAuthenticationChallengeContext context,
  CancellationToken cancellationToken)
{
  context.Result = new ResultWithChallenge(context.Result);
  return Task.FromResult(0);
}
public class ResultWithChallenge : IHttpActionResult
{
  private readonly IHttpActionResult next;
  public ResultWithChallenge(IHttpActionResult next)
  {
    this.next = next;
  }
  public async Task<HttpResponseMessage> ExecuteAsync(
    CancellationToken cancellationToken)
  {
    var response = await next.ExecuteAsync(cancellationToken);
    if (response.StatusCode == HttpStatusCode.Unauthorized)
    {
      response.Headers.WwwAuthenticate.Add(
        new AuthenticationHeaderValue("somescheme", "somechallenge"));
    }
    return response;
  }
}

En el código siguiente se muestra la clase de filtro completada:

public class TokenAuthenticationAttribute : 
  Attribute, IAuthenticationFilter
{
  public bool AllowMultiple { get { return false; } }
  // The AuthenticateAsync and ChallengeAsync methods go here
}

Además de implementar la interfaz IAuthenticationFilter, provengo de Attibute para que esta clase pueda aplicarse como un atributo en el nivel de clase (controlador) o de método (método de acción).

En consecuencia, puede crear un filtro de autenticación con la única responsabilidad de autenticar una credencial específica (un token ficticio en este ejemplo). Un filtro de autenticación carece de lógica de autorización; su único objetivo consiste en controlar la autenticación: establecer una identidad, si la hubiera (mientras procesa el mensaje de solicitud) y devolver un desafío, si lo hubiera (mientras procesa el mensaje de respuesta). Los filtros de autorización se enfrentan a cuestiones de autorización, como comprobar si la identidad es una identidad autenticada o si si está en la lista permitida de usuarios o roles.

Utilizar un filtro de autorización

El objetivo principal de utilizar un filtro de autorización consiste en realizar una autorización: para determinar si un usuario debería tener acceso a un recurso solicitado. La API web ofrece una implementación de un filtro de autorización llamado AuthorizeAttibute. La aplicación de este filtro garantiza que la identidad está autenticada. También puede configurar el atributo de autorización con una lista con los nombres de usuario y de roles concretos que se van a permitir. El código de la Figura 4 muestra el filtro de autorización aplicado a distintos niveles (globalmente, en el nivel del controlador y en el nivel del método de acción) por medio de distintos atributos de la identidad que se va a autorizar. El filtro de este ejemplo garantiza globalmente la autenticación de la identidad. El filtro utilizado en el nivel de controlador garantiza que la identidad está autenticada y que por lo menos uno de los roles asociados a la identidad es "admin". El filtro utilizado en el nivel de método de acción garantiza que la identidad está autenticada y que el nombre de usuario es "badri". Uno de los aspectos que hay que resaltar aquí es que el filtro de autorización en el nivel de método de acción también hereda los filtros de los niveles global y controlador. En consecuencia, para que una autorización sea correcta todos los filtros deben pasar: el nombre del usuario debe ser "badri", uno de los roles debe ser "admin" y el usuario debe estar autenticado.

Figura 4 Uso de un filtro de autorización en tres niveles distintos

public static class WebApiConfig
{
  public static void Register(HttpConfiguration config)
  {
    // Other Web API configuration code goes here
    config.Filters.Add(new AuthorizeAttribute()); // Global level
  }
}
[Authorize(Roles="admin")] // Controller level
public class EmployeesController : ApiController
{
  [Authorize(Users="badri")] // Action method level
  public string Get(int id)
  {
    return “Hello World”;
  }
}

El AuthorizeAttribute no incluido es extremadamente útil, pero si se desea mayor personalización, puede crear clases secundarias para implementar un comportamiento de autorización adicional. En el código siguiente se muestra un filtro de autorización personalizado:

public class RequireAdminClaimAttribute : AuthorizeAttribute
{
  protected override bool IsAuthorized(HttpActionContext context)
  {
    var principal =
      context.Request.GetRequestContext().Principal as ClaimsPrincipal;
    return principal.Claims.Any(c => c.Type ==
      "http://yourschema/identity/claims/admin"
      && c.Value == "true");
  }
}

Este filtro se limita a comprobar la existencia de una reclamación personalizada "admin", pero puede utilizar una entidad de seguridad y cualquier otra información adicional desde HttpActionContext para ejecutar una autorización personalizada.

En la primera versión de ASP.NET Web API, los filtros de autorización personalizados solían utilizarse mal para implementar autenticaciones, pero con ASP.NET Web API 2, los filtros cuentan con su propio lugar en la canalización, lo cual contribuye al desarrollo de un código limpio y modular con las cuestiones de autenticación y de autorización claramente diferenciadas.

Sustitución de filtros

Como he explicado anteriormente, un filtro de autorización puede aplicarse en el nivel de método de acción, de controlador o globalmente. Al especificar globalmente el filtro de autorización, puede exigir la autorización en todas las invocaciones del método de acción de todos los controladores. Si desea que algunos métodos estén exentos de esta configuración global, es más sencillo si utiliza el atributo AllowAnonymous.

El código de la Figura 5 muestra el uso del atributo AllowAnonymous en el nivel de controlador. Si bien el filtro de autorización se aplica globalmente, el atributo AllowAnonymous utilizado con PublicResourcesController exime de autorizar las solicitudes que llegan a este controlador.

Figura 5 Utilización del atributo AllowAnonymous

public static class WebApiConfig
{
  public static void Register(HttpConfiguration config)
  {
    // Other Web API configuration code goes here
    config.Filters.Add(new AuthorizeAttribute()); // Global level
  }
}
[AllowAnonymous]
public class PublicResourcesController : ApiController
{
  public string Get(int id)
  {
    return “Hello World”;
  }
}

AllowAnonymous proporciona un método para que una acción específica pueda reemplazar una autorización configurada por un filtro de autorización de nivel superior. Sin embargo, AllowAnonymous solo le permite reemplazar autorizaciones. Supongamos que desea que se autentiquen la mayoría de las acciones por medio de autenticación HTTP básica, pero que una de las acciones se autentique únicamente con tokens. Sería bueno poder configurar la autenticación con tokens globalmente y, a continuación, reemplazar la autenticación para esta acción, similar a cómo AllowAnonymous reemplaza la autorización.

ASP.NET Web API 2 presenta un nuevo tipo de filtro para este escenario, el filtro de reemplazo. A diferencia de AllowAnonymous, los filtros de reemplazo presentados en ASP.NET Web API 2 pueden funcionar con cualquier tipo de filtro. Los filtros de reemplazo, tal y como indica su nombre, reemplazan los filtros configurados en niveles superiores. Para reemplazar los filtros de autenticación configurados en niveles superiores, utilice el atributo no incluido OverrideAuthentication. Si tiene un filtro de autenticación aplicado globalmente y desea que deje de ejecutarse en un controlador o método de acción específicos, solo tiene que aplicar OverrideAuthentication en el nivel deseado.

Los filtros de reemplazo son útiles para mucho más que para detener la ejecución de determinados filtros. Digamos que tiene dos filtros de autenticación, uno para autenticar un token de seguridad y otro para autenticar un nombre de usuario/contraseña en un esquema HTTP básico. Ambos filtros se aplican globalmente, logrando así que la API sea lo suficientemente flexible para aceptar el token o el nombre de usuario o contraseña. El código siguiente muestra los dos filtros de autenticación aplicados globalmente:

public static class WebApiConfig
{
  public static void Register(HttpConfiguration config)
  {
    // Other Web API configuration code goes here
    config.Filters.Add(new TokenAuthenticator());
    config.Filters.Add(new HttpBasicAuthenticator(realm: "Magical"));
  }
}

Ahora, puede que quiera asegurarse de que solo se utiliza el token como credencial para acceder a un método de acción específico. ¿Cómo le permitirá OverrideAuthentication satisfacer esta necesidad, teniendo en cuenta que detiene la ejecución de todos los filtros? He aquí la característica importante de los filtros de reemplazo: eliminan todos los filtros especificados en niveles superiores pero no en el mismo nivel en el que se encuentran ellos mismos. Esto significa que puede agregar uno o más filtros de autenticación en un nivel específico mientras elimina todo lo demás en niveles superiores. Volviendo al requisito de utilizar únicamente el token como credencial para acceder a un método de acción específico, solo tiene que especificar el atributo OverrideAuthentication y TokenAuthenticator en el nivel del método de acción, como se muestra en el código siguiente (esto garantiza que solo se ejecute TokenAuthenticator en el método de acción GetAllowedForTokenOnly):

public class EmployeesController : ApiController
{
  [OverrideAuthentication] // Removes all authentication filters
  [TokenAuthenticator] // Puts back only the token authenticator
  public string GetAllowedForTokenOnly(int id)
  {
    return “Hello World”;
  }
}

En consecuencia, los filtros reemplazados presentados con ASP.NET Web API 2 ofrecen mucha más flexibilidad globalmente en términos de especificación de los filtros y de ejecutarlos a niveles inferiores selectivamente en los que únicamente donde hay que reemplazar el comportamiento global.

Además del atributo OverrideAuthentication, también hay un atributo no incluido llamado OverrideAuthorization que elimina los filtros de autorización especificados en niveles superiores. En comparación con AllowAnonymous, la diferencia radica en que OverrideAuthorization solo elimina los filtros de autorización de niveles superiores. No elimina los filtros de autorización especificados en el mismo nivel que él mismo. AllowAnony­mous provoca que ASP.NET Web API se salte el proceso de autorización; incluso si hay filtros de autorización especificados en el mismo nivel que AllowAnonymous, simplemente se ignoran.

Resumen

Puede implementar la autenticación en ASP.NET Web API por medio de las opciones ofrecidas por el host, así como los puntos de extensibilidad ofrecidos por la canalización ASP.NET Web API. Las opciones basadas en host se integran bien en la canalización de host y rechazan solicitudes incorrectas de la canalización. Los puntos de extensibilidad ASP.NET Web API proporcionan un nivel de control más preciso en el proceso de autenticación. Si necesita más control de autenticación, por ejemplo, desea utilizar distintos mecanismos de autenticación para distintos controladores o incluso para distintos métodos de actuación, el enfoque correcto consiste en implementar las cuestiones de autenticación por medio de un filtro de autenticación y las cuestiones de autorización por medio de un filtro de autorización.

Badrinarayanan Lakshmiraghavan es arquitecto consultor sernio con una empresa de Fortune 500. Es autor de los libros “Pro ASP.NET Web API Security” y “Practical ASP.NET Web API”, publicados por Apress en 2013. Escribe ocasionalmente en el blog lbadri.wordpress.com.

Gracias al siguiente experto técnico de Microsoft por revisar este artículo: David Matson
David Matson trabaja en Microsoft como desarrollador de software. Es miembro de MVC 5 y del equipo de producto Web API 2.