ASP.NET Authentication and IIS Authentication

for RuBoard

To begin, let's look at a definition of what authentication is. Microsoft defines authentication as

" the process of obtaining identification credentials such as name and password from a user and validating those credentials against some authority. If the credentials are valid, the entity that submitted the credentials is considered an authenticated identity. Once an identity has been authenticated, the authorization process determines whether that identity has access to a given resource."

This "authenticated identity" is the basis for .NET authentication as well as IIS, Windows NT, Windows 2000, and many other platforms' means of not only determining if a user can access a resource, but also to gain information for such tasks as site personalization. Most of the functionality available to developers regarding authentication is exposed through the System.Net library.

Overview of IIS Authentication

IIS provides an interface that ties directly into the Windows operating system on which it is running. This interface allows certain types of authentication to be performed based on accounts at the operating system level. ASP.NET authentication rides on top of the existing structure already provided by Windows servers. IIS provides five ways to allow or deny a user access through a login procedure and two ways to control access based on machine settings and use of certificates. The five ways of authentication provided for in IIS are as follows :

  • Anonymous

  • Basic Authentication

  • Digest Authentication

  • Integrated Windows Authentication

  • Client certificate mapping

Figure 14.1 shows the IIS dialog for selecting which authentication method to use.

Figure 14.1. IIS authentication methods .

graphics/14fig01.jpg

Using Anonymous Access

Anonymous access is allowed by default through a machine account named IUSR_< your machine name here > . This account resides the Guests group of your domain by default. This method allows access to certain resources without users having to identify themselves at all to the server. A few things to watch for when using the anonymous account are as follows:

  • If IIS does not control the password and the password changes on the network, the service will fail. What this means is that if you were to change the password of the IUSR account and IIS was not aware of the change, the services running within IIS would fail.

  • Anonymous lets anybody in unless IP/Site name or certificate restrictions are in place.

  • Make sure the account used for anonymous access is a machine account so that resource access is fairly limited. Another means of handling this is to assign anonymous access to an account on the forest so that Integrated Windows Authentication can be used with SQL Server.

Using Basic Authentication

Basic Authentication is just what it sounds like ”a very basic, not-so-secure way of authenticating or identifying a user. Because Basic Authentication is part of the HTTP 1.0 specification, it is by far the most widely accepted form of authentication. Most commercial proxy servers, Web browsers, and Web servers support Basic Authentication, but the information that a user types in to gain access is not encrypted at all, unless you have implemented SSL, and is basically sending plain text passwords over the network or Internet. In IIS, Basic Authentication uses a domain account list to validate user information. Therefore, any user that you want to authenticate must have a Windows account. It is strongly recommended that, unless it is absolutely necessary, that users created for this purpose are basically limited to the same rights as the "Guest" account that is created by default. Using IIS and SSL for Basic Authentication will allow you to pass credentials on Windows 2000 machines. This can be useful for delegation, but sending a plain text password without SSL for this purpose obviously creates a huge security risk. Also, if you're curious about using Kerberos for Windows 2000, keep in mind the following:

  • Kerberos is only supported on Windows 2000 and later.

  • To use Kerberos , you must have a KDC server ”not something you want the whole world viewing, thus making this most useful on intranet applications.

  • Whatever client you are using, it must be able to support Kerberos as well.

When configuring users to use Basic Authentication in a Windows NT/2000/XP network, you must grant the user a LogonMethod . Most administrators should be familiar with giving a user "Log on Locally" through the user administration interfaces; this is an example of a LogonMethod . The IIS metabase stores settings for managing clear text logons , such as with Basic Authentication. The key of MD_LOGON_METHOD can be set to the following values:

  • 0, the default, for Log on Locally or MD_LOGON_INTERACTIVE

  • 1, for Logon as Batch Job or MD_LOGON_BATCH

  • 2, for Logon over Network or MD_LOGON_NETWORK

NOTE

The reference to editing information that is stored in the IIS Metabase is based on using the tool Metaedit 2.0 from the Windows 2000 Server Resource Kit.


This key can be set at the service, server, directory, virtual directory, and file levels. It cannot be stressed enough that this method of authentication needs to be used in conjunction with SSL if possible to make it a "secure" means of validating credentials. Depending on usage, it may be more viable for you to purchase additional machines to make up for any performance hits from using SSL. This can turn out to be a far less expense than having all of your customers' credit card information sent out by a hacker using a packet sniffer to gain login credentials on your site. If your ASP.NET application needs to run as a user validated by Basic Authentication, you will need to ensure that the web.config file indicates that Windows is the value for the authentication mode attribute. This is illustrated in Listing 14.1.

Listing 14.1 Authentication Mode in web.config
 <system.web>  ...lots of elements  <authentication mode="Windows" />  ... a lot more elements </system.web> 

NOTE

More specific information on implementing SSL on IIS is available through the Microsoft Web site at http://www.microsoft.com/windows2000/en/server/iis/htm/ core /iisslsc.htm or in the Knowledge Base by searching for article Q298805.


Using Digest Authentication

Digest authentication, in a nutshell , is Basic Authentication with a twist. It creates a hash, or digest, of the user's password, the URI requested , and some padding or salt on the client and passes that to the server. Once on the server, the password portion of the hash must be decrypted and then a network login is performed. There are certain immediate pitfalls to using this type of authentication that are very similar to the issues with using Basic Authentication. The first issue is that without SSL, someone could conceivably "record" the actions of a client browser and play them back as if he or she was that user. This would give the attacker the same rights as the original user. The next thing that comes up, especially for Active Directory domains, is that if you plan to use Digest Authentication for users to come in from the outside, their passwords must be stored using reversible encryption. By default, passwords on an AD domain are one-way hashes. In addition to the points raised regarding Basic Authentication, the following must also be considered when implementing Digest Authentication:

  • Digest Authentication currently only works with Microsoft Internet Explorer Version 5.0 and later.

  • Digest Authentication, like Basic Authentication, works with most commercial proxy servers and firewalls.

  • In Active Directory, a user account must exist for each user you want to authenticate.

NOTE

For in-depth information about the Digest Authentication Specification, refer to RFC 2617, available on the Internet at http://www.ietf.org/rfc/rfc2617.txt.


Using Integrated Windows Authentication

Now, we can have some fun. Integrated Windows Authentication is excellent for those times when you have Microsoft-based OS Servers, Microsoft-based OS Workstations, or clients and Microsoft-based Web browsers. The main reason for this is that Integrated Windows Authentication only works with Internet Explorer Version 2.0 and later. The way it works is by sending two WWW-AUTHENTICATE headers in the request when a user attempts to access a protected resource. The first WWW-AUTHENTICATE header will be the NEGOTIATE header, which will determine whether to use NTLM (NT LAN Manager) or Kerberos v5 authentication to perform the network login. If Internet Explorer recognizes the NEGOTIATE header, it will return to IIS information for both NTLM and Kerberos. If the client and the server are running Windows 2000 or later, IIS will decide to use Kerberos. If anything goes wrong, or a null result is returned, IIS and IE will default back to NTLM. Keep in mind that only when using Kerberos authentication on a Windows 2000, or later, network can security credentials be passed around, assuming it has been configured to allow this. More information about credentials and delegation is discussed later in the "Using Impersonation and Delegation in ASP.NET" section later in this chapter.

Using Client-Side Certificates

So, what to do when you have a very large client base? Use certificates. Client certificates allow you to map several users to one Windows 2000 account through certificates. A client certificate is structurally similar to any server certificate. It is used to verify credentials and establish a secure session. Although this method cannot be used to delegate, it is based on PKI (Public Key Infrastructure), meaning that the exchange will require your client's public key and the server's public key to make an exchange. In this method, your server will be issued a certificate by a CA (Certificate Authority). These will also cause the basic SSL communications to begin. The next step is to get the client certificate information and mark it as trusted. This is a very practical method on large internal networks where is it possible to be your own CA through use of Certificate Server and issue certificates to your own clients through your own server. Some of the key points to ponder when using client-side certificates for authentication are as follows:

  • They don't work with all browsers.

  • They require SSL or TLS.

  • They provide a very strong authentication method, just not the easiest to implement.

NOTE

For a step-by-step guide to using client certificates, go to http://www.microsoft.com/windows2000/techinfo/planning/security/mappingcerts.asp.


Using IP Address and Domain Name Restrictions

More of a broad approach to security, rather than an authentication scheme, is the ability to configure restrictions based on a client machine name or IP address.

From the Microsoft Management Console for IIS, an administrator can determine whether to let all machines that attempt to come in through or establish certain groups that do not have permission based on either domain name or IP address. For example, you may have a situation where, on your internal network, the sales department is not allowed to see the financial department's Web site. As an administrator, you configure IIS to block the internal IP address range of the sales department on the Web server that holds the other application. What if they are on the same box? Set up virtual Webs on different ports and map those to a redirect page on the base port. Figure 14.2 illustrates the dialog for setting these parameters in IIS.

Figure 14.2. IP Address and Domain Name Restrictions dialog.

graphics/14fig02.jpg

NOTE

The ability to restrict access by IP address and/or domain name is only available on server installations of IIS. It is not available on PWS or IIS installed on Windows NT, Windows 2000, or Windows XP Professional; however, within Windows XP, the use of IPSec can provide similar functionality.


ASP.NET Authentication Settings

Now that you have an understanding of what is available through IIS, you can look at how to use that to your advantage from ASP.NET. As previously mentioned, the functionality for HTTP client authentication is exposed through the System.Net library. Because System.Net is a vast wealth of functionality for many network functions, we will concentrate on the AuthenticationManager , NetworkCredential , CredentialCache , and WebRequest classes.

The AuthenticationManager class handles the management of the various authentication modules called during a login process. This covers a pretty important process ”the actual authentication of a user. This is provided through the Authenticate() method of the AuthenticationManager class. Listing 14.2 shows the declaration syntax.

Listing 14.2 Authenticate Method (C#)
 public static Authorization Authenticate(    string challenge,    WebRequest request,    ICredentials credentials ); 

Notice that the declaration expects an instance of the ICredentials interface. This is exposed as the NetworkCredential class and the CredentialCache class implements ICredentials . ICredentials exposes the function GetCredentials which, as you might guess, returns a NetworkCredential object associated with a specific URL/URI and whatever authentication scheme you are using. Not clear enough, consider the snippet in Listing 14.3.

Listing 14.3 NetworkCredentials Code Snippet ”Basic/Digest Authentication
 //Create a string to hold the URI value String MyURI = "http://some-server-to-authenticate-to"; //Create an instance of the WebRequest object // to handle the actual request WebRequest WebReq = WebRequest.Create(MyURI); //Now set the credentials for the whatever functionality //you need to perform within this WebRequest, //with these credentials WebReq.Credentials = new NetworkCredential("someusername", "somepassword"); 

In Listing 14.3, if the server name were set to something real that required Basic or Digest Authentication, it would return a WebResponse object that could be traversed using the WebResponse.GetResponseStream() method to begin using information retrieved during the request. The Authenticate() method is called through hierarchy of using the NetworkCredential class.

If you slightly modify this code sample, you can make it work for NTLM or Kerberos authentication as well. Thanks to method overriding features in .NET, the code looks exactly the same, only you add a domain name to the parameter list for the NetworkCredential object. See Listing 14.4 for the complete snippet with changes.

Listing 14.4 NetworkCredentials Code Snippet ”NTLM/Kerberos Authentication
 //Create a string to hold the URI value String MyURI = "http://some-server-to-authenticate-to"; //Create an instance of the WebRequest object // to handle the actual request WebRequest WebReq = WebRequest.Create(MyURI); //Now set the credentials for the whatever functionality //you need to perform within this WebRequest, //with these credentials WebReq.Credentials = new NetworkCredential("someusername", "somepassword", graphics/ccc.gif "somedomainname"); 

Because embedding plain text passwords is not always a good idea for creating a secure application, this same code can be slightly modified yet again to provide authentication for a user who has already logged in. For example, you may have NTLM authentication set up on a particular site; we'll call it Books for this example. According to application guidelines, people in Books can see nothing in the other department of Videos . As an administrator, you need to see it all. This can be managed easily by just letting the NetworkCredential class instantiate with the existing credentials from when you logged in. If a Books person is logged in and attempts to access a resource that is in Videos , an exception will occur that is trappable and should be handled gracefully.

Consider Listing 14.5 for how to use the default credentials of the already authenticated user.

Listing 14.5 NetworkCredentials Code Snippet ”Default User Permissions
 //Create a string to hold the URI value String MyURI = "http://some-server-to-authenticate-to"; //Create an instance of the WebRequest object // to handle the actual request WebRequest WebReq = WebRequest.Create(MyURI); //Now set the credentials for the whatever functionality //you need to perform within this WebRequest, //with these credentials WebReq.Credentials = CredentialCache.DefaultCredentials; 

This works because the user is already logged in and his or her credentials are cached . Each time a user logs in during a session, his or her credentials can be stored in a cache, and this cache is what is accessible through the CredentialClass . This sample not only illustrates the ease with which authentication can be implemented programmatically, it is also a good illustration of inheritance for those who may be new to it.

for RuBoard


. NET Framework Security
.NET Framework Security
ISBN: 067232184X
EAN: 2147483647
Year: 2000
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net