标签：users namespace pos resources ons gis alt filters base
?
You‘ve created a web API, but now you want to control access to it. In this series of articles, we‘ll look at some options for securing a web API from unauthorized users. This series will cover both authentication and authorization.
1
The first article in the series gives a general overview of authentication and authorization in ASP.NET Web API. Other topics describe common authentication scenarios for Web API.
Thanks to the people who reviewed this series and provided valuable feedback: Rick Anderson, Levi Broderick, Barry Dorrans, Tom Dykstra, Hongmei Ge, David Matson, Daniel Roth, Tim Teebken.
Web API assumes that authentication happens in the host. For web-hosting, the host is IIS, which uses HTTP modules for authentication. You can configure your project to use any of the authentication modules built in to IIS or ASP.NET, or write your own HTTP module to perform custom authentication.1
When the host authenticates the user, it creates a?principal, which is an?IPrincipal?object that represents the security context under which code is running. The host attaches the principal to the current thread by setting?Thread.CurrentPrincipal. The principal contains an associated?Identityobject that contains information about the user. If the user is authenticated, the?Identity.IsAuthenticated?property returns?true. For anonymous requests,?IsAuthenticated?returns?false. For more information about principals, see?Role-Based Security.
Instead of using the host for authentication, you can put authentication logic into an?HTTP message handler. In that case, the message handler examines the HTTP request and sets the principal.
When should you use message handlers for authentication? Here are some tradeoffs:
Generally, if you don‘t need to support self-hosting, an HTTP module is a better option. If you need to support self-hosting, consider a message handler.
If your application performs any custom authentication logic, you must set the principal on two places:
The following code shows how to set the principal:
C#Copy
private
void
SetPrincipal(IPrincipal principal)
{
Thread.CurrentPrincipal = principal;
if (HttpContext.Current != null)
{
HttpContext.Current.User = principal;
}
}
For web-hosting, you must set the principal in both places; otherwise the security context may become inconsistent. For self-hosting, however,?HttpContext.Current?is null. To ensure your code is host-agnostic, therefore, check for null before assigning to?HttpContext.Current, as shown.
Authorization happens later in the pipeline, closer to the controller. That lets you make more granular choices when you grant access to resources.
Web API provides a built-in authorization filter,?AuthorizeAttribute. This filter checks whether the user is authenticated. If not, it returns HTTP status code 401 (Unauthorized), without invoking the action.
You can apply the filter globally, at the controller level, or at the level of inidivual actions.1
Globally: To restrict access for every Web API controller, add the?AuthorizeAttribute?filter to the global filter list:
C#Copy
public
static
void
Register(HttpConfiguration config)
{
config.Filters.Add(new AuthorizeAttribute());
}
Controller: To restrict access for a specific controller, add the filter as an attribute to the controller:
C#Copy
// Require authorization for all actions on the controller.
[Authorize]
public
class
ValuesController : ApiController
{
public HttpResponseMessage Get(int id) { ... }
public HttpResponseMessage Post() { ... }
}
Action: To restrict access for specific actions, add the attribute to the action method:
C#Copy
public
class
ValuesController : ApiController
{
public HttpResponseMessage Get() { ... }
?
// Require authorization for a specific action.
[Authorize]
public HttpResponseMessage Post() { ... }
}
Alternatively, you can restrict the controller and then allow anonymous access to specific actions, by using the?[AllowAnonymous]?attribute. In the following example, the?Post?method is restricted, but the?Get?method allows anonymous access.
C#Copy
[Authorize]
public
class
ValuesController : ApiController
{
[AllowAnonymous]
public HttpResponseMessage Get() { ... }
?
public HttpResponseMessage Post() { ... }
}
In the previous examples, the filter allows any authenticated user to access the restricted methods; only anonymous users are kept out. You can also limit access to specific users or to users in specific roles:
C#Copy
// Restrict by user:
[Authorize(Users="Alice,Bob")]
public
class
ValuesController : ApiController
{
}
?
// Restrict by role:
[Authorize(Roles="Administrators")]
public
class
ValuesController : ApiController
{
}
The?AuthorizeAttribute?filter for Web API controllers is located in the?System.Web.Http?namespace. There is a similar filter for MVC controllers in the?System.Web.Mvc?namespace, which is not compatible with Web API controllers.
To write a custom authorization filter, derive from one of these types:
The following diagram shows the class hierarchy for the?AuthorizeAttribute?class.
In some cases, you might allow a request to proceed, but change the behavior based on the principal. For example, the information that you return might change depending on the user‘s role. Within a controller method, you can get the current principle from the?ApiController.User?property.2
C#Copy
public HttpResponseMessage Get()
{
if (User.IsInRole("Administrators"))
{
// ...
}
}
?
Note: about sessionStorage, can refer here: http://www.cnblogs.com/time-is-life/p/7693568.html
Authentication and Authorization in ASP.NET Web API
标签：users namespace pos resources ons gis alt filters base
原文地址：http://www.cnblogs.com/time-is-life/p/7693576.html
