Professional ASP.NET 1.1 [Electronic resources] نسخه متنی

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

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

Professional ASP.NET 1.1 [Electronic resources] - نسخه متنی

Alex Homeret

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

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

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






Authentication and Authorization


In ASP.NET, authentication is the process of establishing identity between the server and a request, to clearly establish that all the server really has is the data sent to it over HTTP. In other words, the server knows nothing about the client other than what the client sends the server. This is important since the application making a request is not always a browser. In fact, it would be wise to get out of the mentality that only web browsers will be making requests against your server.

To establish the identity of a request, the request must follow a protocol that enables a predefined set of rules to be adhered to. For example, almost all HTTP servers support clear text/basic authentication, the pop-up dialog box that asks for a username and password. Clear text/basic authentication follows a protocol such that the browser can properly formulate and encode the request in the format that the server expects.

ASP.NET provides four distinct options for assigning identity to a request:



Forms authentication:Allows you to authenticate requests using HTTP cookies and HTML forms. You can validate identity against any resource.



Passport authentication:Uses Microsoft's single sign-on Passport identity system.



Windows authentication:Allows you to authenticate requests using Windows Challenge/Response semantics. This consists of the server initially denying access to a request (a challenge) and the requestor responding with a hashed value of their Windows username/password, which the server can then choose to authenticate and/or authorize.



Custom authentication:Allows you to roll your own authentication system.




Authentication


ASP.NET's authentication system is very flexible. It supports four modes and various settings for each of these modes. The default mode is

Windows , but you can configure support for the other modes using the

mode attribute of the

<authentication> element:

This attribute has four acceptable settings;

Windows ,

Forms ,

Passport , and

None . This value determines the authentication mode that ASP.NET will enforce. The default is

Windows . If the

mode is set to

Forms , a child element of

<authentication> (called

<forms> ) allows you to define behaviors for forms authentication.

Custom HTML Forms Login


Forms authentication allows you to use HTML forms to request credentials, and then issue an HTTP cookie that the requestor may use for identity on subsequent requests. ASP.NET provides the infrastructure to support this, but also gives the flexibility to choose how you wish to validate credentials.

For example, once you obtain the username and password that has been sent to the ASP.NET application via HTTP

POST (rather than HTTP

GET as it passes the data on the query string), you can validate the credentials against an XML file, a database, an in memory structure, an LDAP directory, or even through a web service!

The validation of credentials is completely up to you. Once the credentials are validated, you can call some of the APIs provided by forms authentication to issue an HTTP cookie to the requestor. On subsequent requests, the cookie is provided along with the request body, and ASP.NET can use the information in the cookie to recreate a valid identity.

The

<forms> element has the following attributes:



name :Forms authentication uses a cookie that contains an ID of the authenticated user. The name of that cookie is defined by the name value of

<forms> . The default setting is

.ASPXAUTH .



loginUrl :When a request comes into ASP.NET with forms authentication enabled, and the request doesn't present a cookie (new user) or has an invalid value within the cookie, ASP.NET will redirect the request to an ASP.NET page capable of logging in the user and issuing the cookie.

loginUrl allows you to configure this value. By default, it is set to

login.aspx and you must provide your implementation of this file.



protection :The value within the cookie can optionally be encrypted or sent in plain text. For sites that simply use forms authentication as a means of identifying the user, you might choose to use no cookie encryption. Valid settings for protection are

All ,

None ,

Encryption , and

Validation .



timeout :Specifies the time in minutes that the cookie is valid for. The timeout of the cookie is reset on each request to the current time plus the timeout value. The default value is 30 minutes.



path :Specifies the path value of the cookie. By default this is set to

/ , the root of the server. Cookies are only visible to the path and server that sets the cookie. ASP.NET forms authentication chooses to use the root of the server as the path, since the path value in a cookie is case-sensitive.



requireSSL (ASP.NET 1.1):Defaults to

false , but when set to true requires that the Forms Authentication cookie is sent using SSL. Using SSL for sending the cookie provides a better measure of security.



Within

<forms> there is also a

<credentials> sub-element, which can optionally be used to define users.





Note

As you will learn in Chapter 14, when we use forms authentication, you can validate users from any data store.


Defining Users for HTML Forms Authentication


Nested within the

<forms> element is a

<credentials> element.

<credentials> allows you to define users (identities) and passwords directly within your configuration file, although this is completely optional. You can choose to take advantage of this section, or can choose to define identities in another location.





Important

Use of the

<credentials> section is not required. Instead, the validation of the username and password can be custom-coded, such as validation of username/password pairs stored in a database.


The

<credentials> section allows you to define

<user> entries. This section is used to optionally store your usernames and passwords in the configuration file.

<credentials> supports a single attribute,

passwordFormat . This attribute tells ASP.NET the password format used by the

password value of

<user> . Supported values include

SHA1 ,

MD5 , and

Clear . However, simply setting this value does not automatically encrypt the value of

password . It is the developer/administrator's responsibility to add the value of the

SHA1 or

MD5 hashed password into the configuration file.

Nested within

<credentials> are

<user> entries. The

<user> entries are used to define valid usernames and passwords against which to authenticate. A

<user> entry contains two attributes –

name and

password – that together are compared against when we attempt to authenticate requests.

If you choose to store your usernames and passwords in the configuration file, you are provided with several options for password hiding. The

<credentials> tag supports a single

passwordFormat attribute. This attribute can be set to one of three values:



Clear :Value of the password for

<user> entries is stored in clear text. For example,

password="password" .



SHA1 :Value of the password for

<user> entries is stored as a

SHA1 hash. For example,

password="5B9FEBC2D7429C8F2002721484A71A84C12730C7" (value is password). Hashing will be discussed in the next chapter.



MD5 :Value of the password for

<user> entries is stored as an

MD5 hash. For example,

password="2BF3023F1259B0C2F607E4302556BD72" (value is password).



Rather than storing clear text values within the

<credentials> section for

<user> entries, you can store hashes of the password. If your configuration file is compromised, the users' passwords are safer than if they were stored as clear text.

An example of storing the username and password in the credentials section is shown next. The

passwordFormat is set to

SHA1 and the value for

password represents a

SHA1 hash of the user's password:

<configuration>
<system.web>

<authentication mode="Forms">

<forms name=".ASPXAUTH" loginUrl="login.aspx"

protection="all" timeout="30" path="/" >

<credentials passwordFormat="SHA1">

<user name="SomeUser" password="83jksjfi3983ksl23dscdf"/>

</credentials>

</forms>

</authentication>
</system.web>
</configuration>



Passport Authentication


When Passport is installed on the server, ASP.NET's Passport integration can be utilized to authenticate users, based on whether they present a valid Passport with their request. The Passport is a token granted to a given request that enables the request to be authenticated by applications that trust Passport IDs.

The token is stored in a site-specific cookie after authenticating with

login.passport.com . You can use the

redirectUrl attribute of the

<passport> authentication option to control where non-authenticated Passport users are directed. For example:


<passport redirectUrl="/Passport/SignIn.aspx">


Depending upon how you configure your site's authorization (discussed next), this may be the only page that Passport users are allowed to access.





Note

We will explore authentication in more detail in Chapter 14.



Authorization


The

<authorization> configuration settings allow you to set access control permissions, defined as

<allow> and

<deny> settings, used to control access to resources. Both follow the same format for entries:

<[allow | deny] users="users | * | ?" roles="roles"/>

For example:

<configuration>
<system.web>

<authentication mode="Forms">

<forms name=".ASPXAUTH" loginUrl="login.aspx"

protection="all" timeout="30" path="/" >

</forms>

</authentication>

<authorization>

<allow users="Stephen, Brian, Rob" roles="Administrator, Customer" />

<deny users="?" roles="BlackList" />

</authorization>

</system.web>
</configuration>






Note

Note the ordering of the

<allow> and

<deny> . This controls how the authorization is enforced,

<deny> should follow the

<allow> .


In the configuration settings, we define authorization settings that allow the users

Stephen ,

Brian , and

Rob as well as the

Administrator and

Customer roles. However, anonymous users (identified by

? ) and users that belong to the

BlackList role/group will be denied access. Any users or roles that are denied access will be redirected to the

loginUrl specified in the authentication settings, since the server will attempt to re-authenticate the user.

/ 244