Authorization
As
mentioned earlier, authorization is the second phase in the process of
determining whether or not a client has the right to issue a particular
request. Authorization refers to determining if the user identity
determined during the authentication phase is allowed to access the
requested resource.
IIS 7.0 provides several authorization mechanisms that can be leveraged to control access to resources:
NTFS ACL-based authorization
By default, IIS 7.0 verifies that the authenticated user identity has
the right to access the physical file or folder corresponding to the
requested URL. This check is performed only for requests that map to
physical files or directories and use authentication methods that
produce Windows tokens. This authorization mechanism has multiple usage
limitations that are discussed in detail later in this section.
URL Authorization
The new IIS 7.0 URL Authorization role service enables applications to
create declarative configuration-based rules to determine which
authenticated users and/or roles have the right to access the Web site
or specific URLs therein. This feature replaces the IIS 6.0 URL
Authorization feature, which is no longer supported.
ASP.NET URL Authorization
The ASP.NET URL Authorization feature, available since ASP.NET 1.0, is
similar to IIS URL Authorization, with a slightly different
configuration syntax and rule processing behavior. ASP.NET applications
that use this feature today can configure it to control access to all
Web site content when they run using ASP.NET integrated mode.
In addition,
developers can provide custom authorization features by developing
modules by using the IIS 7.0 native module APIs or the ASP.NET APIs for
applications using ASP.NET Integrated mode. In fact, you can use most
existing ASP.NET authorization modules immediately in applications that
are using ASP.NET Integrated mode. This makes it significantly easier to
develop custom authorization features that implement business
authorization rules and can leverage the powerful ASP.NET membership and
role infrastructures.
In the remainder of this section, we will review the authorization features in detail.
NTFS ACL-based Authorization
The
IIS 7.0 server engine (rather than a module) automatically performs
NTFS ACL-based authorization. During this authorization, the Web server
checks that the authenticated user identity has the rights to access the
physical file or folder being requested.
Note
NTFS
ACL-based Authorization is part of the IIS Web server core and
therefore is always installed when the Web server is installed. Though
it cannot be uninstalled or disabled, you can remove one of the
requirements in the following list to configure your application to not
use it. |
This authorization occurs automatically when all of the following conditions are met:
The
authenticated user identity must have a Windows token. If the request is
authenticated using an authentication method that does not provide
Windows tokens, for example Forms Authentication, this authorization is
not performed.
The
selected handler mapping for the request specifies a resource type of
File, Directory, or Either. Some mappings use the resource type of
Unspecified to enable requests to virtual URLs that do not have a
corresponding physical resource on disk. For these handler mappings,
this authorization is not performed.
Note
Most
ASP.NET handler mappings are marked as Unspecified by default. However,
ASP.NET includes additional functionality that ensures that if the URL
maps to a physical file or folder, the access check is performed (with
the exception of content located in a virtual directory that stores its
files on a UNC path). |
The
request URL maps to a physical file or folder that exists on disk. If
the file or directory does not exist, IIS does not perform the check.
The
virtual directory corresponding to the request being made does not
specify fixed access credentials. If the virtual directory specifies
fixed credentials, they will be used to access all content for the
virtual directory, and therefore IIS does not use the authenticated user
to check access.
In addition, for you to successfully use NTFS ACL-based authorization, the following conditions must also be true:
The
physical resources have ACLs configured to properly grant or deny access
to each authenticated user. This is typically done by placing all of
the allowed users in a group, and granting this group access to the
content.
If the
virtual directory corresponding to the request refers to a remote UNC
share and does not specify fixed UNC credentials, the authenticated user
identity must be able to delegate
to the remote server. This requires basic authentication, or requires
Constrained Delegation or Protocol Transition to be configured.
Because
of the aforementioned limitations and the overhead of managing NTFS ACL
permissions for multiple users, NTFS ACL-based authorization is not
recommended as a generic mechanism for restricting access to IIS
resources. Use it only if your application meets the preceding
requirements and you would like to use ACLs as an authorization
mechanism (for example, if you are sharing static resources for users
with domain or local machine accounts, and the resources already have
the right permissions configured).
Because this authorization happens automatically for physical resources, you must
configure all required resources to grant access to the authenticated
identities that need to use your application.
URL Authorization
The IIS 7.0 URL
Authorization feature is new in IIS 7.0. It provides a way to configure
declarative access control rules that grant or deny access to resources
based on the authenticated user and its role membership.
Note
URL
Authentication is not part of the default IIS install. You can manually
install it from the Windows Features IIS feature category through
Windows Features on Windows Vista or from the Security role service
category of the Web Server (IIS) role in Server Manager on Windows
Server 2008. |
Unlike NTFS ACL-based authorization, URL Authorization has the following advantages:
It is
not tied to authentication schemes that produce Windows identities. It
can be used with any authentication schemes, including Forms
Authentication, which produces custom authenticated user identities.
It
enables rules to be configured for specific URLs, not underlying files
or directories. Therefore, it is not tied to specific resource types and
does not require files or directories to exist.
It
stores authorization rules in the configuration, instead of NTFS ACLs.
These rules are easier to create and manage, and they can be specified
in distributed web.config files that travel with the application when it
is deployed or copied between servers.
It
integrates with the ASP.NET Membership and Roles services, which
enables custom authentication and role management modules to provide the
authenticated users and their roles. You can use ASP.NET Forms
Authentication with Membership and Roles to quickly deploy a data-driven
user and roles credential store for your application.
Note
The
IIS 7.0 URL Authorization feature is new. It is not related to the
similarly named IIS 6.0 URL Authorization feature, which is overly
complex, difficult to configure, and not widely used. The IIS 6.0 URL
Authorization feature is not included with IIS 7.0. |
The ASP.NET URL
Authorization feature inspired the new URL Authorization feature, which
implements similar functionality. However, some key differences exist in
how rules are configured and processed. We’ll discuss these differences
later in this section.
Using URL Authorization to Restrict Access
To use URL Authorization
to restrict access to your application, you need to configure one or
more URL Authorization rules. These rules can be configured at the Web
server level. Alternatively, you can configure them for a specific Web
site, application, or URL. This makes it very easy to use URL
Authorization to quickly restrict access to any part of your Web site to
a specific set of users or roles.
These rules can be one of the following types:
Allow An allow rule grants access to the resource being requested and allows request processing to proceed.
Deny A deny rule denies access to the resource being requested, rejecting the request.
Both types of rules
can specify a set of users, roles, and/or verbs that URL Authorization
uses to match each rule to the request. As soon as a rule matches, the
corresponding action (Allow or Deny) is taken. If the request is denied,
URL Authorization will abort request processing with a 401 unauthorized
response status code. If no rules matched, the request will also be
denied.
Unlike ASP.NET URL
Authorization, the deny rules are always processed before allow rules.
This means that the relative order between deny and allow rules does not
matter. In addition, the order between rules defined by parent
configuration levels and the current configuration level does not
matter, because all deny rules from all levels are always processed
first, followed by all allow rules. Finally, the default behavior when
no rules match is to deny the request.
By default, URL
Authorization has a single rule configured at the Web server level that
provides access to all users. You can restrict access to your Web site
or a part of it by creating authorization rules by using the following
techniques:
- Remove
the default allow rule for all users and create explicit allow rules
only for users and roles that should have access to the current URL
level. This way, by default, all requests will be denied unless the
authenticated user or role matches the configured allow rule. This is
the recommended practice, because it ensures that only the configured
users and roles have access to the resource, and it denies access to
everyone else.
- Create explicit deny rules for users and roles that should not
have access to the current URL level. This may be appropriate to
prevent access for only the specific users and roles. However, it is not
generally a secure practice, because the set of users and roles is
typically unbounded. The exception to this rule is the technique of
creating a deny all anonymous users rule to restrict access only to
authenticated users.
Note
When
designing the access control rules for your application, prefer to
grant access to roles instead of specific users. This makes it easier to
manage authorization rules as more users are added. |
See the following section titled “Creating URL Authorization Rules” for information on configuring URL Authorization rules.
Creating URL Authorization Rules
You can use IIS
Manager to configure URL Authorization rules by selecting the desired
node in the tree view and double-clicking Authorization Rules. In the
resulting window shown in Figure 1,
you can see the list of rules currently in effect at the level you
selected, which will include both the rules configured at higher
configuration levels and the rules configured at the current
configuration level.
You
can remove existing authorization rules (including parent authorization
rules that are not locked) by selecting them in the list and clicking
Remove in the Actions pane. You can add an allow or deny rule by
clicking Add Allow Rule or Add Deny Rule in the Actions pane. Figure 2 shows an allow rule that can be used to allow access to all users or specific users or roles.
You can also edit URL Authorization rules by configuring them directly in the system.webServer/security/authorization
configuration section, by using Appcmd from the command line, or by
using configuration APIs. This configuration section is unlocked by
default to facilitate storing URL authorization rules in your
application’s web.config files, which enables them to travel with the
corresponding application content when deploying the application to
another Web server.
To add a URL authorization rule with Appcmd, you can use the following syntax.
%systemroot%\system32\inetsrv\Appcmd.exe set config [ConfigurationPath]
/section:system.webServer/security/authorization
"/+[users='string',roles='string',verbs='string',accessType='enum']"
To delete a URL authorization rule with Appcmd, you can use the following syntax.
%systemroot%\system32\inetsrv\Appcmd.exe set config [ConfigurationPath]
/section:system.webServer/security/authorization
"/-[users='string',roles='string',verbs='string']"
The parameters to these commands are shown in Table 1.
Table 1. Parameters for Adding URL Authorization Rule
| Parameter | Description |
|---|
| ConfigurationPath | The configuration path at which this configuration is set. |
| users | The
comma-separated list of user names that this rule allows or denies.
Each user name is matched with the user name of the authenticated user
set for the request, and the rule matches as soon as a single user
matches (or a role matches). For Windows identities that represent
domain accounts, use the domain qualified user name format of
“domain\user” rather than the fully qualified domain name format of
“user@domain.com”. Use “*” to refer to all users and “?” to refer to
anonymous users. The default is “”. |
| roles | The
comma-separated list of roles that this rule allows or denies. Role
membership for each role is tested for the authenticated user set for
the request, and the rule matches as soon as a single role matches (or
user matches). The default is “”. |
| verbs | The
comma-separated list of verbs (case-sensitive) that matches the request
verb. If specified, one of the verbs must match the request verb for
the rule to apply. The default is “”. |
| accessType | Whether
the rule should allow or deny access. Accepted values are Allow and
Deny. This parameter must be specified to add a rule. |
Using ASP.NET Roles with URL Authorization
In applications using
the ASP.NET Integrated mode, it is possible to configure the ASP.NET
Roles feature to provide application-specific roles for each
authenticated user. IIS 7.0 URL Authorization rules can specify access
rules that use roles provided by the .NET Roles feature or another
ASP.NET module to implement application-specific authorization schemes,
much like the original ASP.NET URL Authorization feature. You can learn
about setting up the ASP.NET Roles feature at http://msdn2.microsoft.com/en-us/library/9ab2fxh0.aspx.
When the .NET Roles
feature is enabled, and a role provider is configured for your
application, you can begin configuring URL Authorization rules that rely
on these roles in your application. To make sure that the roles are
available for requests to non-ASP.NET content types, be sure to remove
the managedHandler precondition from the RoleManager module. For
information about enabling managed modules to run for all requests by
removing the managedHandler precondition.
You can also
create roles directly using IIS Manager by selecting the application
node in the tree view and then clicking.NET Roles. In the resulting
page, you can manage existing roles, create new roles using the
configured Role provider for the application, and associate application
users with roles.
