Building Microsoft ASP.NET Applications for Mobile Devices, Second Edition [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Building Microsoft ASP.NET Applications for Mobile Devices, Second Edition [Electronic resources] - نسخه متنی

Andy Wigley; Peter Roxburgh

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
توضیحات
افزودن یادداشت جدید






User Authorization

Once you have transferred an HTTP request from the mobile device over an encrypted channel to the Web server and you have authenticated the client's identity, you must then put your mind to deciding what that user is allowed to do—that is, you authorize the user. Central to this is determining the identity of the process that is running your application. This identity depends on the form of authentication you have chosen.

Whenever your mobile Web application runs on the Web server, it does so using a Windows identity. Effectively, your process (which is running the ASP.NET worker process aspnet_wp.exe) logs on as a Windows user. By default, an ASP.NET application runs using the machineName\ASPNET identity. This default ASPNET account is specially configured to run with the minimum possible set of privileges. For example, you'll find that by default your application can access only specific folders that are required to run a Web application, such as the \bin directory in which a Web application stores compiled files, it cannot create new processes, or create new event log categories.

The account that ASP.NET Web applications run under is configured in the machine.config file in \Windows(or Winnt)\Microsoft.NET\Framework\version\config by the <processModel> element:

<processModel username="machine" password="AutoGenerate" />

The machine username indicates the ASPNET account. The password is maintained and secured by the system. If your application is running under the ASPNET account, you will need to configure NTFS permissions and Windows ACLs to allow access to specific resources. If you access resources over the network, you will have to set the ASPNET password to a specific value, record it in the

<processModel> element, and then create an account also named ASPNET with the same password on the remote system.

If you set the username attribute of <processElement> to "system", the ASP.NET worker process runs as the local SYSTEM account. This is not recommended, as it makes your machine vulnerable to attack if your Web application is compromised.


Impersonating a User


Instead of running under the nonprivileged ASPNET account, you can use impersonation by setting <identity impersonate="true"> in the application's Web.config file, whereby the ASP.NET process runs with the identity (and security context) of the authenticated user. Access to resources is then controlled through normal NTFS access controls.

The <identity> element has two usages:

<identity impersonate="true"/>
<identity impersonate="true" username="Andy" password="P455w0rd"/>

Use the first form to run the ASP.NET process under the identity of the user as authenticated by IIS. This could be a Windows user account if HTTP Basic authentication is used. If Anonymous access is configured in IIS, it could be the IUSR_MACHINENAME account, where MACHINENAME is the NetBIOS name of the computer specified at install time.

Using the second form, you can specify a fixed account to be used for authenticated users by specifying values for the username and password attributes. This is not recommended in .NET Framework 1.0 because you had to grant the ASPNET process identity the "Act as part of the operating system" privilege, which makes your Web server more vulnerable to attack from hackers. In .NET Framework 1.1, the ASPNET account does not need this privilege. Also, in .NET Framework 1.1, you are able to store the username and password in the Windows registry in encrypted form. See the .NET Framework SDK documentation for the <Identity> element for details of how to do this.

Whether you use a fixed account or the identity of the authenticated user, you must apply access controls to allow the account read/write access to the %installroot%\ASP.NET Temporary Files directory and to the application directory. The account must also have read access to the %systemdrive%\inetpub\wwwroot and the %windir%\assembly directories, so that ASP.NET can access the content files and can monitor file changes.


URL Authorization


Once you have determined the identity that your application is running under, you can authorize access to secure resources. You use the <authorization> element in the <system.web> section of a Web.config file to control which users and groups of users should have access to the application.

The <authorization> element has two child elements that you use to allow or deny access to resources. The two elements are <allow> and <deny>, which both have three attributes. Table 18-4 describes these three attributes.





















Table 18-4: Attributes of the <allow> and <deny> Tags


Attribute


Description


Users


The users that have permission to access the resource. The attribute's value is a comma-separated list of users. You can substitute names with wildcard characters. You can use a question mark (?) to refer to anonymous users and an asterisk (*) to refer to all users.


Roles


The .NET roles that have permission to access the resource. The attribute's value is a comma-separated list of roles.


Verbs


The HTTP methods that have permission to access the resource. The attribute's value is a comma-separated list of methods, in which the possible values include GET, HEAD, POST, and DEBUG.


If you're using ASP.NET Windows authentication (<authentication mode="Windows"/>), you are authorizing against Windows accounts and groups, so usernames and roles take the forms DomainName\Username and DomainName\WindowsGroup, respectively, as shown in the following code. (With Windows authentication, .NET roles map one-to-one with Windows groups.)

<allow users="MyDomainName\Bob"/>
<allow roles="MyDomainName\Administrators"/>

If you're using Forms authentication, you are authorizing against the username that you validated against, regardless of whether that username was configured in the <credentials> elements in Web.config or whether you validated against a database or Active Directory. Specify just the name for users or roles, as shown here:

<allow users="Bob"/>

If you're using Passport authentication, you are authorizing against the Passport User ID (PUID) or against roles mapped to the PUID that your application has retrieved from a database.

At run time, the authorization module iterates through all the <allow> and <deny> tags until it finds the first match for the requesting user. This is then used to allow or deny access to the URL. The following XML from an application's Web.config file shows how you can configure an application to authorize users:

<configuration>
<system.web>


<authorization>
<deny verbs="GET,HEAD"/>
<allow users="josh@adatum.com,max@adatum.com"/>
<allow roles="Admins"/>
<deny users="*" />
</authorization>


</system.web>
</configuration>


This code instructs ASP.NET to deny all GET and HEAD requests. If the request comes from a permitted method, such as POST, the users josh@adatum.com and max@adatum.com and the Admins role can access the resource. ASP.NET will deny access to all other users.

Usually, <authorization> settings in Web.config refer to all the files in the current directory and all subdirectories (unless a subdirectory contains its own Web.config file with an <authorization> element—in which case, the settings in the subdirectory override those of its parent). However, you can use the <location> tag to apply authorization settings to a particular file or directory. The following example shows how you can apply authorization to a specific page:

<location path="admin.aspx" />
<authorization>
<allow users="josh@adatum.com,max@adatum.com"/>
<allow roles="Admins"/>
<deny users="*" />
</authorization>
</location>

/ 145