| After IIS has authenticated the user, it passes the request and the user identity to the appropriate worker process. The worker process uses this identity to check the NTFS permissions on the ASPX template files. If the ACLs on template files do not grant at least read access to the user, access is denied. We will now examine under what identity the request may be processed. NOTE: To configure the security settings in the ASP.NET environment, machine.config is used for machine-wide settings, and web.config is used for application-specific settings
ASP.NET Impersonation By default, ASP.NET runs under a special account identity. This account has a limited number of privileges. In IIS 5, this account is called ASPNET. By default, the worker process will access all resources using this account identity regardless of what identity has been passed by IIS, unlike classic ASP, which uses the identity passed by IIS. NOTE: The default permissions for the ASPNET account are explained in detail in Knowledge Base article 317012.
In certain scenarios, the default account permissions are not sufficient, and we need to configure the worker process to use a different identity for processing requests. This is called ASP.NET impersonation, and the new identity can be set up in several ways: On a machine-wide basis for all Web applications (in IIS 5 and in IIS 6 running in IIS 5 isolation mode) For an application pool (in IIS 6 running in worker process isolation mode) For a particular Web application Using the credentials of a user who has made a request
To configure ASP.NET impersonation on a machine-wide basis for IIS 5, you need to edit the <processModel> section of the machine. config file. This section contains user name and password entries for the account credentials used by ASP.NET for example: <processModel...username="MACHINE" password="AutoGenerate".../> The default for "username" is MACHINE, which causes ASP.NET to assume the ASPNET account identity; the default for "password" is AutoGenerate, which causes ASP.NET to use a cryptographically strong random password stored in the Local Security Authority (LSA) for that account. The account can be changed to either a named user account or SYSTEM. SYSTEM causes ASP.NET to use the local system account. Although in certain situations you may need to use the SYSTEM account, bear in mind that it has almost unlimited privileges. If you want to change an ASP.NET runtime identity to a user account, change the user name and password in the <processModel> section, as follows: <processModel...username="domain\user" password="password".../> In this scenario, the user name must be qualified with the domain name for the domain account, or the local server name for the local account. The disadvantage is that the user name and password are stored in machine.config in clear-text format. NOTE: The Aspnet_setreg.exe utility, available from microsoft.com, provides the ability to encrypt these attributes and store their values in the registry under a secure key. For detailed instructions, refer to Knowledge Base article Q329290.
CMS and Domain Controllers In general, it is not advisable to run your CMS server on a domain controller, because a compromise of the server is a compromise of the domain. However, if you need to use the Windows 2000 domain controller, you will have to change the default ASP.NET process identity because there is a known problem with using the ASPNET identity on Windows 2000 domain controllers. ASPNET is configured as a local account; it is a member of a built-in Users local group. However, on a domain controller, all user accounts are domain accounts and are not local machine accounts. As a result, on domain controllers, ASP.NET fails to start because it cannot find a local account named <localmachinename>\ASPNET. The solution is either to create a new account with the same permissions as ASPNET, which is recommended, or to use a local system account. In any case, you need to change the <processModel> section of the machine.config file accordingly. Full information about this bug is provided in Microsoft Knowledge Base article 315158. |
In IIS 6, the worker process identity in IIS 5 isolation mode is configured using the processModel element in exactly the same way as in IIS 5. However, in worker process isolation mode, the worker process identity is configured in a different way, using the application pool properties. By default, in IIS 6 a worker process runs as a Network Service. To change the worker process identity, right-click the application pool you would like to configure, select Properties, and click the Identity tab. Then, you can select either Predefined or Configurable options. The Predefined option allows you to select Network Service or Local Service, or Local System identities. The Configurable option allows you to explicitly specify the account name and password under which you want your worker process to run. If you wish to configure impersonation for the CMS Web application, you need to edit the <identity> element in the web.config file. NOTE: The web.config file for the CMS Web application is created by Visual Studio .NET when you create a CMS project in VS.NET; it is located at the root of your CMS Web application.
There are three settings for the <identity> element that you can use. <identity impersonate="false"/>: This is the default setting. It turns off impersonation and causes the worker process to use the default identity. <identity impersonate="true"/>: This setting causes the worker process to adopt the identity of the user making a request within the CMS Web application. This is the identity that is passed on by IIS. If IIS uses Anonymous authentication, then this identity will be IUSR_<machinename>; if IIS uses any other authentication mechanism, it will be an authenticated Windows user identity. All processing for the request will be performed under this identity. <identity impersonate="true" name="domain\user" password="password"/>: This setting provides the ability to specify the account to be used by ASP.NET within the CMS Web application. Once again, the user name must be qualified with the domain name for the domain account, or the local server name for the local account; and the password is stored in web.config in clear-text format.
NOTE: As before, you can encrypt the "username" and "password" attributes and store their values in the registry under a secure key using the Aspnet_setreg.exe utility, available from microsoft.com.
ASP.NET Authentication ASP.NET provides its own authentication systems that we can use within the CMS Web application; these systems are called ASP.NET authentication providers. ASP.NET authentication providers are implemented as HTTP modules that are defined within the HTTP pipeline in machine.config. These modules contain the code necessary to authenticate user credentials; they are identified in the <httpModules> section of the machine.config file, as follows: [View full width] <httpModules> ... <add name="WindowsAuthentication" type="System.Web.Security  .WindowsAuthenticationModule"/> <add name="FormsAuthentication" type="System.Web.Security .FormsAuthenticationModule"/> <add name="PassportAuthentication" type="System.Web.Security .PassportAuthenticationModule"/> ... </httpModules>
The use of authentication providers within ASP.NET allows us, for example, to implement anonymous access for IIS and pass all requests from IIS through to the application for authentication. This approach is particularly well suited for public access Internet sites. ASP.NET authentication will always occur in the HTTP runtime, after IIS authentication. ASP.NET authentication is configured using the <authentication> element within the web.config file. There are four possibilities. None: This mode specifies that ASP.NET doesn't perform any authentication, but provides the ability for the ASP.NET runtime to accept every request that is passed on from IIS. This mode is specified using the <authentication mode="None"/> element in web.config. Windows authentication: This mode is designed to be used in conjunction with IIS authentication; it validates users against Windows security accounts. It is the default authentication mode; for CMS projects, it is configured when VS.NET creates a web.config file for the project. Windows authentication is useful when you want to use impersonation; it retains the user account identity passed on from IIS. You can use it with the Basic, Digest, and Integrated Windows authentication methods in IIS. If IIS is configured for anonymous access, this mode will verify that the IUSR_<machinename> account is valid. This mode is specified using the <authentication mode= "Windows"/> element in web.config. As we discussed in the previous section, in order to provide impersonation, you need to use the <identity impersonate = "true"/> element in web.config. If you enable impersonation, then resources accessed by your application such as files, folders, registry keys, and Active Directory objects are accessed with the user identity. If you don't enable impersonation, which is disabled by default, then your application uses the default worker process identity to access resources. However, the user identity is used in both cases with or without impersonation to access the ASPX files and other ASP.NET files; the difference is in accessing resources programmatically from the code at runtime. Forms authentication: This method uses HTML forms, client-side redirection, and authentication tickets stored in cookies. If IIS is configured for anonymous access, all authentication is handled by ASP.NET. Forms authentication relies on a WebForm interface and therefore is not dependent on any specific client-side features or functionality; all modern browsers support the HTML <form> tag. This is how it works: The user requests a page. Since the user does not have a valid authentication ticket, access to the resource is denied. The request is redirected to a login page, as defined in web.config. The user enters credentials in the login page, and they are sent to the server. The login page verifies the credentials. You can verify against Windows security accounts, or you can verify against your own list of users and their credentials. This can be in any form for example, a SQL database, an XML document, or even a text file. The user is given an ASP.NET Forms authentication cookie, which identifies the user as authenticated. Subsequent requests from the browser automatically include the cookie. If the cookie is passed from the browser, ASP.NET accepts the request as authenticated; if there is no cookie in the request, or it has expired or is otherwise invalid, then the user is redirected to the logon page.
The Forms authentication mode is specified by setting the <authentication> element to Forms mode in web.config for example: <authentication mode="Forms" > <forms loginUrl="login.aspx" name="MyCookie" path="/" protection="All" timeout="30"/> </authentication> The <forms> element in our example defines the name and location of the login page; the name of the form that will become the name of the authentication cookie; the cookie lifetime in minutes; the path of the cookie to be set on the client; and the level of cookie protection set to "All," which instructs ASP.NET to both encrypt and validate authentication cookies. To make sure the user credentials are not intercepted, you are strongly advised to protect the login page with SSL. In this case, all data transmitted between the browser and the server will be encrypted, including the user credentials. Passport: This mode performs authentication using the Microsoft Passport service. Microsoft Passport allows Internet users to establish a single centralized storage for a set of credentials that can be used on any Passport-compliant Web site. Passport authentication uses a ticketing scheme: Once the user logs on to any Passport-compliant site, the central Passport service provides a ticket in an in-memory cookie. The Passport authentication provider within ASP.NET checks whether a ticket is present in the request; if it's not present or is invalid, then the user is redirected to the Passport login. Passport verifies the user credentials, issues a ticket, and redirects the user back to the originally requested page.
The authentication mode is an application-wide setting that can only be set in the application root web.config file. You cannot use forms-based authentication in one part of your application and Windows authentication in another. ASP.NET Authorization Authentication mechanisms allow us to verify the user's identity; but to determine what they can do, we need authorization. Authorization is set up in web.config using the <authorization> element. This element defines the list of users and groups that are permitted or denied access to the CMS Web application. NOTE: When referring to groups, in the ASP.NET environment the term "roles" is used. When using Windows authentication, roles and groups mean the same thing; however, for Forms authentication the meaning is different.
The authorization settings are contained within the <authorization> element; they consist of <allow> and <deny> elements that allow and prohibit access. There are special characters for anonymous users and all users; for example <deny users="?"/> denies anonymous users; <allow users="*"/> allows all users. The <allow> and <deny> elements are evaluated in sequence; those that match the user identity are applied. The authorization entries in web.config differ depending on the authentication provider you use, as follows: Authorization for Windows authentication: The user and group names must match the security accounts in the Windows account database; for domain accounts, the user and group names must be prefixed with the domain name. Let's look at the following example: <authorization> <deny users="?"/> <deny users="CMS/UserNotAllowed"/> <allow roles="CMS/administrators"/> <deny users="*"/> </authorization> In this example, anonymous access is blocked, as well as the access for a user named UserNotAllowed from the CMS domain. Access for the administrators group from the CMS domain is allowed, and, finally, all other users are denied access. The sequence is important: If UserNotAllowed was a member of the administrators group, the user would be denied access because the directive for UserNotAllowed occurs first. Authorization for Forms authentication: With Forms authentication, there is no concept of a domain; user names are just the names we pass on from the login page. ASP.NET checks the authorization section in web.config before it redirects the request from the login page to determine their permissions. As far as groups are concerned, if you want to use them you may need to add some code to the AuthenticateRequest event in global.asax. This event is raised when the authentication provider attempts to authenticate a user, even if authentication fails. Your code needs to establish group membership at runtime. The names of the groups you create in the code must match the roles defined in web.config. For example, in your code you may read the group names from the database. Let's look at an example of an <authorization> element for Forms authentication: <authorization> <deny users="?"/> <allow users="administrator"/> <allow roles="PremierUsers" <deny users="*"/> </authorization> In this example, anonymous users are denied access, while a user named "administrator" and a group called PremierUsers are allowed access.
|
