HttpChannel Web Security
Web security is based on the Internet standards for encrypted communication and authentication. The HttpChannel class uses managed networking on the sender and Internet Information Services (IIS) with ASP.NET on the receiver to provide Web security. The credentials (Username, Password, and optionally Domain) can be set in the HttpChannel properties. The remoting infrastructure passes the credentials to System.Net, which sends them to the server. The channel message sink properties contain a PreAuthenticate property that by default sends the credentials with the first message.
Authentication
Applications hosted in ASP.NET can be configured for authentication using the combination of IIS and ASP.NET security. The ASP.NET application virtual directory is configured for security in IIS and ASP.NET. See the IIS documentation and Securing ASP.NET Web Applications for details on configuring IIS and ASP.NET for authentication.
Secure Communication in ASP.NET
The HttpChannel hosted in IIS with ASP.NET supports sending and receiving encrypted communication using Secure Sockets Layer (SSL). See the IIS documentation for configuring SSL. Include the text https and the appropriate URL at the start of calls to Activator.CreateInstance, Activator.GetObject, items in the .NET remoting configuration file, or anywhere URLs are used to specify a remote object, remote XML Web service, or remoting application.
To determine whether the HTTP connection is encrypted, call the HttpContext.Request property to obtain the HttpRequest object, and then call HttpRequest.IsSecureConnection.
Anonymous
Use this option to allow users to establish an anonymous connection. Your server lets the user log on with an anonymous or guest account.
**Note **You must turn off Anonymous if you want to use Basic, Digest, or Integrated Windows authentication.
Basic Authentication
Basic authentication is a security mechanism using a standard HTTP mechanism in which user information is sent and received as clearly readable text characters rather than binary bit-streamed information. Basic authentication uses a base64-encoded string that contains the user name and password. Passwords and user names are encoded but not encrypted in this type of authentication. It is important to note that Basic authentication results in the transmission of passwords across the network in an unencrypted form. A determined unauthorized user equipped with a network-monitoring tool could intercept user names and passwords.
Basic authentication can be useful when the application just needs some identifier for the calling application.
Digest Authentication
Digest authentication sends a hash value, rather than the password, over the network. This method works across proxy servers and other firewalls.
Digest authentication is a challenge-response scheme that challenges using a nonce (a server-specified data string) value. A valid response contains a checksum of the user name, the password, the given nonce value, the HTTP method, and the requested Uniform Resource Identifier (URI).
Digest authentication addresses many of the weaknesses of Basic authentication. Most notably, the password is not transmitted in clear text when you use Digest authentication. Digest authentication can also work through proxy servers, unlike Integrated Windows authentication.
Digest authentication is useful when the application needs a stronger level of authentication than Basic.
Cookie Authentication
Cookie authentication is generally used to refer to a system whereby unauthenticated requests are redirected to an HTML form using HTTP client-side redirection. The user provides credentials and submits the form. If the application authenticates the request, the system issues a cookie that contains the credentials in some format or a key for reacquiring the identity. Subsequent requests are issued with the cookie in the request headers and are authenticated and authorized by an ASP.NET handler using whatever validation method the application requires.
Note that Cookie authentication is often used for personalization, where content is customized for a known user. In some of these cases, identification is the issue rather than authentication, so it is enough to merely store the user name (in a durable cookie) and use that name to access the personalization information.
Integrated Windows Authentication
Integrated Windows authentication uses a cryptographic exchange with the user's Microsoft Internet Explorer.
Integrated Windows authentication (formerly known as both NT LAN Manager (or NTLM) and Windows NT Challenge/Response authentication) is more secure than Basic authentication. This authentication scheme works especially well in an intranet environment where users have Windows domain accounts.
In Integrated Windows authentication, the browser attempts to use the current user's credentials from a domain logon. If those credentials are rejected, Integrated Windows authentication prompts the user for a user name and password by means of a dialog box. When Integrated Windows authentication is used, the user's password is not passed from the client to the server. If a user has logged on as a domain user on a local computer, the user will not need to be authenticated again when accessing a network computer in that domain.
The user is not prompted for a user name and password for each HTTP request; rather, the dialog box appears only when the cached credentials do not have sufficient permissions to access a specific page or file.